Re: /usr/bin/env behaviour?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 9 Nov 2008 09:39:19 -0500
    From:        "matthew sporleder" <msporleder%gmail.com@localhost>
    Message-ID:  
<b0459d5c0811090639x2cadfbfdk851ead6ef0549050%mail.gmail.com@localhost>

  | The various man pages are all pretty unclear.  :)

What you quoted there for Solaris, OS X and FreeBSD is
their behaviour for additional args on the cmd line that
invokes the script, only for the Linux case did the extract
even mention the #! line interpretation itself.

When the #! code was first written (by Dennis Ritchie, I was
told, though I never asked him about it) all it allowed was a
single path name to the interpreter - no extra args at all.

When I added it to BSD, I made a conscious decision to permit
exactly one arg - not a general command line.   That avoided the
need for the kernel to contain an arg parser, or for any kind of
quoting mechanism (I decided that allowing spaces in the interpreter
path name was so unlikely to ever be required that we could just
ignore that possibility - and no-one I know has ever complained
about that one...).

Exactly one arg (or none) on the #! line remains the most common practice
I believe, though I have heard of systems that have extended it.
How they handle quoting issues I have no idea, I probably don't want
to find out.


For what it is worth, I think the practice of using env is just
laziness on the part of the developer of the script (not creating
a mechanism to fill in the correct interpreter path when installing
the script).   It isn't needed with pkgsrc which does provide that
mechanism.

It isn't desirable as it means the script never really knows which
version of some command with the same name it is going to get.
For example, if in my $HOME/bin I were to put a program called "perl"
which had nothing at all to do with Larry Wall's programming language,
the "env" invocation method would try to use my program (searching PATH
is its purpose after all) rather than the intended one from /usr/pkg/bin
(or wherever).

Since I never run perl (the language) any more, other than as required
by something else I'm running, installing something different called perl
might be an entirely reasonable choice for me.

kre