On Wed, Dec 05, 2001 at 02:49:58AM +0900, Hugh Sasse Staff Elec Eng wrote:
> On Wed, 5 Dec 2001, Martin Weber wrote:

The points I mentioned were meant as a response to the url the 
original poster gave, which argue for hardcoding the path.

Considering your question why i think it's arrogant:

"I have perl in /usr/bin/perl so better everybody has it in /usr/bin/perl"
this attitude adresses non-portability, too. With portable I meant portable
across *nix platforms, like linux *vs.* *BSD *vs.* Solaris vs. ....

Considering users who should know what they're doing:

I was referring to *nix systems. One of its weaknesses is that users need
to have a thorough knowledge about the system they're using. If you want
to make it easier to have a 'plug+play' system you surely don't want to 
have clueless users change your scripts.

*nix systems should be SuSv2-compliant ;) which defines 'env' and its location

If I write software I want people to be able to use it easily, all they
should need to know is what the script (which sometimes turns out to be
a big bad huge program, not a "dirty little script") will do, not which
interpreter is used or where to find this one. I've had enough "bug-reports"
from a couple of people who work in a department as chip-designers, using
unix as their platform as of the availability of certain software for it,
that the program I've wrote for them wouldn't work, because dumb me hard-
coded the path in the first place.

As of all those reasons I think it's more reasonable to use a non-hardcoded
path.

I have to agree with your point about clueless users and the PATH variable,
otoh if a user starts fiddling with that he could as well change a hardcoded
path. I'm talking about ease of use :)

So, pardon if I was too much on the perl path, I hope this all adresses
ruby finding its interpreter, as well as my main point, the ease of use
for the (targetted) end-user. 

In the end I have to admit, though, that there is no 'perfect' way. Sigh :(

Martin Weber