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

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

Re: diffutils-2.8


From: Bob Proulx
Subject: Re: diffutils-2.8
Date: Tue, 11 Jun 2002 19:35:51 -0600
User-agent: Mutt/1.3.28i

> The configure script for diffutils-2.8 should set DEFAULT_DIFF_PROGRAM
> in config.h to be
> 
>       "${prefix}/bin/diff"
> 
> instead of just
> 
>       "diff"
> 
> When you run GNU sdiff it eventually does an
> execvp(DEFAULT_DIFF_PROGRAM, (char **) argv).
> With DEFAULT_DIFF_PROGRAM defined as "diff", then you'll end up running
> whichever "diff"
> is first in your ${PATH}.  If the vendor "diff" isn't GNU diff, then
> this will cause problems.

I am not a diff developer.  But that is just the way I want it.  I set
PATH to select the version and type of utilities that I want to
access.  If I want a stock vendor environment then I only have
/usr/bin et al in my path.  If I want GNU tools then I put the GNU
tools bin directory early in my path.  If I am most fortunate then I
am already working on a GNU OS machine and /usr/bin is GNU.

Also accessing these tools may mean accessing utilities across NFS if
I am on a stock vendor machine without the good stuff installed.
Which means when I access /net/myhomemachine/opt/local/bin/sdiff that
if it hard codes the path to /opt/local/bin/diff that it won't be the
"right" one.  Pulling utilities off of PATH is the only way that
works.

When you say you will run "whatever diff is first in your ${PATH}" you
seem to think that is a bad thing.  Don't you control your own PATH in
your own environment?  That is not something a vendor controls.  If
you are wanting the GNU tools wouldn't you be setting your PATH such
that you would be getting the GNU tools?

Also, you left out the comment from the config.h.

/* Name of "diff" program, unless overridden. */
#define DEFAULT_DIFF_PROGRAM "diff"

You can always override this for your own compilation.  (And the
reverse is true for me since I have always had to do that in the past.
But since I see this as progress I don't want to take a step
backward.)

Bob

"Hard coded paths are rarely good."



reply via email to

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