CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]

[Coleman Kane]

On Wed, 2008-06-18 at 09:23 -0700, Doug Barton wrote:
> pfgshield-freebsd at yahoo.com wrote:
> > On 2008-06-17, Gabor Kovesdan wrote:
> >>> egrep: empty (sub)expression
> >>> 
> >> I've looked at this and I have a patch with a workaround: 
> >> http://kovesdan.org/patches/grep.dougb.diff
> > 
> > This general behavior should be considered a GNUism, the type of
> > thing that we want to avoid in scripts. Perhaps, if it's too
> > common, the workaround should be ifdef'd into a GNU compatible mode
> > or something.
> 
> No, "here is a new bsd grep, but change all your scripts that have 
> relied on legitimate behavior of grep in the past" is a non-starter. I 
> haven't checked POSIX to see whether the particular construction I am 
> using fits the spec or not, but I really don't care. We need to be 
> feature-compatible with the GNU versions of these tools, both for 
> legacy scripts and also for those users migrating over from linux.
> 
> Doug
> 

I think that this is the second time that I've seen this type of issue
come up (oh no! A GNU-ism sneaks in! Oh, the horror! The horror!).

Seriously, I really see this attitude as counter-productive to getting
wider acceptance of the project. I don't think FreeBSD's (or any BSD's)
mission statement ever involved "ridding the *NIX world of the decidedly
impure habits of the GNU system". I always thought it was more along the
lines of "lets make an OS, that is better than the GNU system, and
free-er too".

The above statement, critical of GNU grep, does not offer any insight
into what "the right way" (read: not the GNU way) is. Such
"proclamations" are justifiably going to elicit the responses along the
lines of Doug's response.

Honestly, in this case you can either choose to pick up BSD grep
yourself and do the work, or not drop in to chastise someone for
mirroring a "GNU-ism" behavior. How about coming up with a script that
parses all these "GNU-ism offenders" and corrects the GNU-isms into
POSIX-compliant behavior? 

How about at least explaining what you think the proper way to do it
using our grep should be?

Here's my take on it:
  * We reject "||", "(|", and "|)" (via our regex lib) right now
  * GNU grep seems to interpret that as inclusive-or '' (which causes
the OR to match an "empty string" for that field, and basically allow it
to not exist and still match).
  * We want to remove the empty disjunction with this patch?

The above seems to indicate that even the posted fix is not going to
operate the same as it does under GNU... From a logical point-of-view, a
disjunction that contains "empty" should match an empty, so in that
sense the GNU grep behavior has a logical basis.

For example, take five strings { "aba", "ab", "abc", "ac", "an" }

The GNU pattern "^a(b|)c$" could match "abc" and "ac" because the "empty
string was explicitly matched". The solution proposed, however, would
only match "abc". Logically, there's a basis for performing the GNU
method (even in my Automata course).

So perhaps try explaining rather than shooting down. Just because GNU
does it doesn't mean it should be immediately tossed out (and *must* be
wrong). The people who develop Linux and the GNU tools generally are a
perfectly competent and intelligent bunch, even though their ideology
may differ. If that weren't the case, then we wouldn't be using their
grep in our base system in the first place.

If we want to remove the behavior from our system, we'll need to find
all cases of (a|b||c) and convert them into (a|b|c){0,1} (if the latter
is even possible on BSD grep). Only if the expression is (a|b||c)* can
it safely become (a|b|c).

-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080618/ec3fe056/attachment.pgp