[Top][All Lists]

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

bug#17246: grep-2.19 planning

From: Paolo Bonzini
Subject: bug#17246: grep-2.19 planning
Date: Sat, 12 Apr 2014 21:48:53 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Il 12/04/2014 21:35, Paul Eggert ha scritto:
Paolo Bonzini wrote:
I'm not sure that the complexity of C programs will be smaller than the
complexity of grep <=2.18's machinery.

Unfortunately that machinery wasn't clearly separated from everything
else, and this was confusing.  Having it be a separate script will make
it clearer.  A nice plus is that the scripts are tiny.

You are comparing apples-to-oranges.

I've said multiple times that I'm willing to put effort into simplifying the current grep/egrep/fgrep implementation.

And the matcher machinery, no matter how confusing it is, is not breaking anything, while the scripts might have unanticipated problems with relocatability, copying binaries around, --program-prefix and friends, and perhaps others I have not thought about.

One remaining problem with C wrappers is that they make the grep
installation non-relocatable and "non-separable".

They are still relocatable in the sense that if you move grep + egrep +
fgrep together to some other directory, they'll continue to work
together in the typical case.  That's good enough for a hack to support
an obsoleted interface.

Stop referring to it as obsoleted! The GNU coding standards say that GNU "considers" standards, it doesn't "obey" them.

It does not matter if it is obsolete*d*, it matters if it is obsolete, i.e. if nobody is using it---and that's obviously not the case, especially for fgrep.


reply via email to

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