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

[Stepan Kasal]

Hallo,
        thnak you for explaining me the issue.
When I look back to my post, I guess it wasn't very bright.
I'll try to do better today ;-)

On Wed, 29 May 2002 12:52:07 -0400, Paul Jarc <address@hidden> wrote:
> It can be exported if the server and client agree on a path that will
> refer to the mount point on both systems.

Sure, I had this in mind, but I didn't want to make the mail even longer.

> 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?

I think this is the best possible solution as far as scripts are concerned.

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

I had a private e-mail discussion with Martin Kraemer (the orig. poster).
I have also mentioned this variant and he replied:

> If you compare the problem with GNU "ls" vs. "vdir", then it looks like
> ls has already solved it by creating several copies:
> 
> -r-xr-xr-x  1 root  wheel  64496 17 Nov  2000 /usr/local/bin/dir
> -r-xr-xr-x  1 root  wheel  64496 17 Nov  2000 /usr/local/bin/gdir
> -r-xr-xr-x  1 root  wheel  64496 17 Nov  2000 /usr/local/bin/vdir
> 
> I know that, many moons ago, ls used to be a hard link to vdir.

So we have three variants:
1) symlinks
2) scripts (with hardwired paths)
3) copies of binaries

I still don't understand why are the guidelines aginst the old symlinks variant
(BTW, the code is still there in grep.c from 2.5.1 ;-)
Could someone please explain me where this idea comes from?
Does it represent a security risk?

Could all of these variants be just install options?
(Probably --enable-* options to the configure script?)
If I prepare a patch, does it have a chance to be accepted?

Thanks in advance for (even more) explanation,
                Stepan Kasal