Re: /usr/bin/env behaviour?

["matthew sporleder" <msporleder%gmail.com@localhost>]

On Mon, Nov 10, 2008 at 11:47 AM, Robert Elz <kre%munnari.oz.au@localhost> 
wrote:
>    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.
>

Actually, it's more popular in python as shown here:
http://docs.python.org/tutorial/interpreter.html#executable-python-scripts

This all sounds reasonable to me, I was just trying to see what
different systems did.

I managed to actually test with the following script:
#! /usr/bin/env ls -l

Solaris:
silently ignores the extra args

os x:
accepts the extra args and executes

linux, netbsd, and freebsd
Give an error from env.