[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/45430: ash uses argv as $0 for scripts without #!
The following reply was made to PR bin/45430; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
Subject: Re: bin/45430: ash uses argv as $0 for scripts without #!
Date: Sat, 5 Nov 2011 17:13:41 +0000
On Thu, Oct 06, 2011 at 01:08:54PM +0300, Nikolai Kondrashov wrote:
> > ?This isn't a bug!
> > ?For a normal program binary argv is whatever the user typed, this
> > ?also applies to non #! scripts executed by the shell.
> > ?The execution of #! scripts is done by the kernel which has to
> > ?pass the interpreter the full pathname of the script file.
> Sorry, I forgot #! scripts are executed by the kernel for a moment,
> while looking for a reason to change this (wishful thinking?).
> I agree that this is not strictly a bug from the architecture standpoint.
> However, in the user's view this may seem strange and inconsistent and
> could be confusing.
> Especially considering bash, dash, busybox, zsh, csh, and tcsh (but
> not ksh) do supply full path in $0 in that case.
> It seems a practical thing to do.
valkyrie% cat test
valkyrie% sh -c './test'
valkyrie% csh -c './test'
valkyrie% ksh -c './test'
valkyrie% bash -c './test'
valkyrie% tcsh -c './test'
valkyrie% zsh -c './test'
Anyway, I think what you're doing is almost certainly a mistake. By
convention the value of argv is whatever the invoker supplies, and
with most shells by (mostly tacit) convention that is the path used to
invoke the program if a path was given (with at least one slash) and
just the name if the program was found somewhere on $PATH. In some
cases the full path will get substituted; and, as David Laight hinted
at, for a setuid script the value won't be the file at all but
something in /dev/fd. (Not that sh scripts should ever be setuid...
However, relying on the full path to be substituted (or for that
matter, even relying on it to be a name for the running script) is a
bad idea, because it might not be.
There's probably a better way to do what you're trying to accomplish.
> Details, if anyone is curious:
This gives me a blank page.
> If nothing else, could you please confirm that the patch above doesn't
> break anything?
No such luck...
David A. Holland
Main Index |
Thread Index |