bug-gnu-utils
[Top][All Lists]
Advanced

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

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


From: Stepan Kasal
Subject: Re: [grep-2.5] Option '--program-prefix=g' behaves incorrect
Date: Wed, 29 May 2002 09:12:05 +0000 (UTC)
User-agent: slrn/0.9.6.2 (Linux)

Hallo,

On Tue, 28 May 2002 17:29:25 +0200, Martin Kraemer wrote:
>   ./configure --program-prefix=g --prefix=/opt/SMAW/gnu
> 
> But the resulting paths after "make install" did not satisfy me:
> 
> lrwxrwxrwx   1 root          4 May 28 17:20 /opt/SMAW/gnu/bin/egrep -> grep
> lrwxrwxrwx   1 root          4 May 28 17:20 /opt/SMAW/gnu/bin/fgrep -> grep
> -rwxr-xr-x   1 root     123796 May 28 14:43 /opt/SMAW/gnu/bin/ggrep
> 
> i.e., the binary (and also the man pages) were renamed allright, but
> the symbolic links are broken.

thanks to Martin Kraemer for reporting the bug.

I looked to the source, hoping the fix would be easy.  I've found instead that
the relevant parts of the scripts has changed recently.

Because of a ridiculous requirement (originating from a wise comitee, I'm
afraid) that a program cannot set its default behaviour according to the name
by which it was called, the symlinks were replaced with tiny scripts

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

In this case, similarily as with the previous one, we have to change "grep"
to "ggrep" and perhaps rename "egrep" to "gegrep" and "fgrep" to "gfgrep."
That would be trivial but...

The attitude with these tiny script is IMHO much worse then with symlinks.
Consider the situation which Martin Kraemer seems to have used before:
the system has its own version of grep and we have GNU version of it
installed in another directory.

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!"

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.

3) We can deduce the path from $0.  Since we speak about non-GNU systems, we
cannot rely on "dirname" (it would be too expensive, anyway).

        exec ${0%/*}/grep -E "$@"

It seems that $0 always contains a slash, even in cases when the script has
been fund using $PATH.  (I have verified this on Linux and HP-UX.)
But if this assumption wasn't true, we'd be deemed to use:

        f="/$0"
        d=${f%/*}
        exec ${d:+${d#/}/}grep -E "$@"

and that would be real black magic.


"Gimme back old time symbolic! It was good for bearded hackers, it's good
enough for me!"
(Well traditionally they were hard, but symlinks are better.)

Seriously: if this standard has to be followed, what about dropping the
egrep and fgrep support completely?  The sysadmin or distribution builder
can decide themselves better what they need.
In most cases an alias will be probably the best solution.
This attitude will surely bring more protests, but also much less confusion.

Good luck to GNU,
        Stepan Kasal



reply via email to

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