From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2001-12-05T05:04:11+09:00
Subject: [ruby-talk:27479] Re: Shebangikowksy

On Wed, 5 Dec 2001, Martin Weber wrote:

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

The good thing about standards is that everyone can make their own :-)
>
> 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

Yes, this is a weakness of Unix, it is pretty harsh for users. We adapt
to it, rather than vice versa.

> to make it easier to have a 'plug+play' system you surely don't want to
> have clueless users change your scripts.

"Plug and Play" has never really been a unix metaphor -- it is more like
"solder and test"  -- much more powerful, flexible, and unforgiving. :-)

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

Agreed.

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

I understand your frustration with this.  Users don't know what
information to supply when things go wrong, and the diagnostics they see
are either "A device isn't working" (Windows NT example, actually)
or something in hex (or worse).

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

Yes, your position is clearer to me now.
>
> In the end I have to admit, though, that there is no 'perfect' way. Sigh :(

I think that is the case.  I think that it is the ease of use of the
shells that is the problem here:  if the shell could do the right thing
more often this would not be a problem.  The idea of having everything
in PATH is simple and efficient, necessary for systems that Unix was
designed for originally.  Something more sophisticated might be useful
now; the CPU power and RAM exist to support such sophistication. If the
diagnostics were better this would help too.

This tends to suggest that a shell with more knowledge about the system
embedded in it might be useful.  For example, if you get your ruby
distribution tar file, and

$ tar -zxf ruby*
$ cd ruby*

you will get an error message.  Only one of the ruby* can be the right
operand for cd, but the shell can't figure that out, and do the right thing.

This is the only solution I can think of at the moment.  Most shell
implementations are designed for programmers and those who delight it
the power and flexibility of such expressions as

find . -type f -name "core" -exec rm -i {} \;

rather than the users whom the systems are supposed to serve.
Maybe this ties in with Matz' Human Oriented Programming philosophy
in some ways, but I think this is drifting off topic now! :-)

The books at
http://www.cooper.com/cooper_books.htm
discuss this sort of thing at some length  (I have no financial interest
to declare, wrt those :-).)

>
> Martin Weber
>
	Hugh