Re: grep-2.5.1a egrep/fgrep PATH problem

[Tony Abou-Assaleh]

Are assuming that grep will be "installed"? It is often not
the case, especially in academic places on big unix server that have a
default unix grep.

I know one could use the --prefix with configure, and that's something
that we should incorporate into these scripts (if it's not already), but
in many cases, one simply copies the binaries to a convenient location
(e.g., if you don't care about the man pages and stuff).

There seem to be good arguments for both multiple binaries and for
wrappers, which all points to the fact that we should be offering the user
the option. I like the wrapper idea for system-wide installs, but prefer
the binaries for manual installs (especially on solaris).

Cheers,

TAA

--------------------------------------------------
Tony Abou-Assaleh
Ph.D. Candidate, Faculty of Computer Science
Dalhousie University, Halifax, NS, Canada, B3H 1W5
Fax:   902-492-1517
Email: address@hidden
WWW:   http://www.cs.dal.ca/~taa/
---------------------[THE END]--------------------


On Fri, 24 Jun 2005, Charles Levert wrote:

> * 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).
>
>