bug-grep
[Top][All Lists]
Advanced

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

Re: grep-2.5.1a egrep/fgrep PATH problem


From: Charles Levert
Subject: Re: grep-2.5.1a egrep/fgrep PATH problem
Date: Fri, 24 Jun 2005 02:45:45 -0400
User-agent: Mutt/1.4.1i

* On Thursday 2005-06-23 at 19:34:53 -0700, Paul Eggert wrote:
> Charles Levert <address@hidden> writes:
> 
> > egrep fgrep: Makefile
> >     (echo '#! /bin/sh'; \
> 
> Shouldn't the shell name be configured?

On the one hand, is there any system that
supports #! but doesn't have a /bin/sh?

On the other hand, this could help mitigate
the shell portability problem if we knew what
specific shell we were generating a script for.


> >     echo 'p="'`echo grep|sed '$(transform)'`'"' ; \
> >     echo 'case "$$0" in' ; \
> >     echo '  */*)' ; \
> >     echo '    d="$${0%/*}/"' ; \
> 
> The ${0%/*}/ construction won't work in older shells: I suspect
> they'll exit immediately when they detect it.

Possible.  One more reason to scrap this.


> More important, this style of solution still doesn't conform to the
> GNU coding standards.  For example, if I install grep into
> /usr/local/bin and then move /usr/local/bin/fgrep to /usr/bin, then
> the new /usr/bin/fgrep won't work as desired: it will call
> /usr/bin/grep rather than /usr/local/bin/grep.

How about this, then?

We store the grep executable as

   /usr/libexec/grep/2.5.2/i686-pc-linux-gnu/grep

That would give it a canonical home, while
enabling several versions to co-exist on one
system, something that's hard to do under /bin,
unless we use

   /bin/grep-2.5.2

Some may argue that it would pollute /bin,
but this would also make sure it's on /bin's
filesystem as a fundamental utility, not
/usr/libexec's which may not yet be mounted.

(And if someone really wants to have several
2.5.2, we can allow for an extra-version string
or some other compile-time override of the
version string, if it doesn't already exists.)

This executable would no longer support
invocation-name dependent behavior.

If symlinks are supported, /bin/grep can directly
point to that executable with the version
somewhere in the linked-to path:

   ln -s /usr/libexec/grep/2.5.2/i686-pc-linux-gnu/grep /bin/grep

or

   ln -s grep-2.5.2 /bin/grep

Otherwise, it can be a wrapper.

Both fgrep and egrep would always be wrappers.

All wrappers would have the above full path
(always with version string) hardcoded in them,
and would try nothing else.  Standardize exit
127 if the exec fails.

Wrappers could again be one-liner shell scripts
using ${1+"$@"} (or detect zsh to route around
its brain damage regarding that).

   #! /bin/sh
   test -n "${ZSH_VERSION+set}" && alias -g '${1+"$@"}'='"$@"'
   exec /bin/grep-2.5.2 -F ${1+"$@"}
   exit 127

Alternatively, wrappers could be trivial C
programs using execve().  I don't know how
portable that is (to non-UNIX-like systems,
that is).




reply via email to

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