[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17246: grep-2.19 planning

From: Paul Eggert
Subject: bug#17246: grep-2.19 planning
Date: Mon, 12 May 2014 12:40:11 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]