NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/45430: ash uses argv[0] 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>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/45430: ash uses argv[0] 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[0] 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.
 
 Do they?
 
 valkyrie% cat test
 echo "$0"
 valkyrie% sh -c './test'
 ./test
 valkyrie% csh -c './test'
 ./test
 valkyrie% ksh -c './test'
 ./test
 valkyrie% bash -c './test'
 ./test
 valkyrie% tcsh -c './test'
 ./test
 valkyrie% zsh -c './test'
 ./test
 valkyrie% 
 
 Anyway, I think what you're doing is almost certainly a mistake. By
 convention the value of argv[0] 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...
 but still.)
 
 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:
  > https://plus.google.com/109969355357893765097/posts/2tmx3gmK3yY
 
 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
 dholland%netbsd.org@localhost
 


Home | Main Index | Thread Index | Old Index