bug#17246: grep-2.19 planning

[Paul Eggert]

Paolo Bonzini wrote:
> I didn't get an answer as to _what_ exactly is simplified by the patches
> to introduce the wrapper shell scripts.

Overly-convoluted logic that was hard to follow.  For example, in grep-2.18:

  if (MB_CUR_MAX == 1 || !match_icase
      || ! (matcher
            && (STREQ (matcher, "fgrep") || STREQ (matcher, "pcre"))))
    return execute (buf, size, match_size, start_ptr);

Now, what does "matcher &&" mean there?  If 'matcher' is null, we are 
using grep and no matcher has been specified; as it happens (though 
there's no comment to this effect) 'matcher' cannot be null in fgrep 
even when a matcher has not been specified.  So "matcher &&" means "(we 
are not using the grep matcher) &&".  This code is correct, but it's 
confusing, and this caused Norihiro to propose even-more-confusing 
patches like this in 
<http://lists.gnu.org/archive/html/bug-grep/2014-03/msg00058.html>:

  if (match_icase && MB_CUR_MAX > 1 && keycc
      && ((!matcher && STREQ (matchers[0].name, "fgrep"))
          || (matcher && STREQ (matcher, "fgrep"))))

Here the second line is unnecessary -- or perhaps I'm not understanding 
things correctly, but then the code is *really* confusing.

Grep maintainers shouldn't have to worry about stuff like this. 
Instead, we should separate the concerns of egrep and fgrep, so that 
they do not affect the mainstream grep code.

> Have you evaluated the effect
> of the patch on things like help messages or error messages for things
> like "egrep -F" or "fgrep -E"?

Yes, the patch made these diagnostics better.  In grep 2.18:

$ egrep -F xxx
egrep: egrep can only use the egrep pattern syntax

which is an ungrammatical tautology.  In the latest snapshot:

$ egrep -F xxx
grep: conflicting matchers specified

This is simpler, shorter, easier to maintain, more consistent with grep 
-E, and is one less diagnostic to translate.