[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: /usr/bin/env behaviour?
On Mon, Nov 10, 2008 at 11:47 AM, Robert Elz <kre%munnari.oz.au@localhost>
> Date: Sun, 9 Nov 2008 09:39:19 -0500
> From: "matthew sporleder" <msporleder%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
> 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:
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
silently ignores the extra args
accepts the extra args and executes
linux, netbsd, and freebsd
Give an error from env.
Main Index |
Thread Index |