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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:32 UTC