Re: [grep-2.5] Option '--program-prefix=g' behaves incorrect

[Paul Jarc]

address@hidden (Stepan Kasal) wrote:
> egrep:        #!/bin/sh
>       exec grep -E ${1+"$@"}
>
> The parameter is just an improved replacement of the traditional $*, this is 
> OK.
> (BTW: I don't understand why simple "$@" is not enough.)

Some shells expand "$@" like "" (a single empty argument) when there
are no arguments.  ${1+"$@"} correctly expands to no arguments on
those shells.

However, it breaks on zsh, which is used as /bin/sh on Mac OS X,
unless you first do:
case "$ZSH_VERSION" in ?*) alias -g '${1+"$@"}'='"$@"';; esac

> 1) Just "exec grep" would call the first grep on the path, which
> could lead to unpleasant bugs: "I have explicitly called GNU egrep
> by specifying the full path!"

Right; I think this bug has already been reported.

> 2) So we can write a fixed path to the script during the install phase.
> But this means that such "executable" cannot be moved or exported via nfs.

It can be exported if the server and client agree on a path that will
refer to the mount point on both systems.  I think the grep maintainer
said the full paths would be put in the scripts in the future.  How
often do you really need to move programs?

> 3) We can deduce the path from $0.

No, we can't.  If I make a symlink to the script and invoke it by that
symlink, $0 will contain the symlink's name, not the pointed-to name.
My symlink will not necessarily have grep adjacent to it.

> Since we speak about non-GNU systems, we cannot rely on "dirname"
> (it would be too expensive, anyway).
>
>       exec ${0%/*}/grep -E "$@"

This (enhanced parameter expansion) is probably less portable than
dirname.

> It seems that $0 always contains a slash, even in cases when the script has
> been fund using $PATH.

If it is found in $PATH, yes.  But not in the (pathological) case of:
execve("script-in-current-directory", ...);

> Seriously: if this standard has to be followed, what about dropping the
> egrep and fgrep support completely?

That is definitely unacceptable; it would break other code using egrep
and fgrep.

Separate compiled programs acting like grep -E and grep -F by default,
regardless of their names, would avoid all the problems above, but
would take extra space.  There's always a tradeoff.

> The sysadmin or distribution builder can decide themselves better
> what they need.

Similarly, you can remove the scripts if you don't need them.


paul