Date: Sat, 8 Feb 2003 21:47:45 GMT
From: abc AT anchorageinternet DOT org
Message-Id: <200302082147.h18Lljri034387@en26.groggy.anc.acsalaska.net>
X-Authentication-Warning: en26.groggy.anc.acsalaska.net: abc set sender to abc AT anchorageinternet DOT org using -f
Subject: #! bash bug
X-Mailer: Umail v2.9.2
To: djgpp AT delorie DOT com
Reply-To: djgpp AT delorie DOT com

apologies for my previous brain damaged email ...
i finally got some sleep.  this is the result of
a post i made to see what other developers say.

this does seem to be an ambiguous area, so,
even after sleeping, i think it's more sane
to allow arguments to a script given to an
interpreter on the shebang line, passing
everything after "#!/interpreter [arg]"
to an "eval" or "sh -c" ...

i mean, the current method is a can of worms unnecessarily.

#!/bin/sh -x            this is obviously ok.
#!/bin/sh -vx           this is obviously ok too.
#!/bin/sh -c"string"    this is obviously not ok, but why shouldn't it be?
#!/bin/sh -c "string"   this is obviously not ok, but why shouldn't it be?
#!/bin/sh script        this is obviously ok.
#!/bin/sh -n script     this is obviously not ok, but why shouldn't it be?
#!/bin/sh script 1 2    this is obviously not ok, but why shouldn't it be?

it seems that only a minority of execve() man pages / implementations
are preventing the sane solution ...

> > say i have 2 scripts, scriptA and scriptB.
> >
> > scriptA
> > -------
> > #!/bin/sh ./scriptB 1 2 3
> >
> > scriptB
> > -------
> > #!/bin/sh
> >
> > echo 0:$0
> > echo 1:$1
> > echo 2:$2
> > echo 3:$3
> >
> > --
> >
> > $ ./scriptA
> >
> > $0:./scriptB
> > $1:1
> > $2:2
> > $3:3
> >
> > --
> >
> > according to execve(2), only a single [arg] should be recognized:
> >
> >     #! interpreter [arg]
> >
> >      When an interpreter file is execve'd, the system actually execve's
> >      the specified interpreter.  If the optional arg is specified, it
> >      becomes the first argument to the interpreter, and the name of the
> >      originally execve'd file becomes the second argument; otherwise, the
> >      name of the originally execve'd file becomes the first argument.  The
> >      original argu- ments are shifted over to become the subsequent
> >      arguments.  The zeroth argument is set to the specified interpreter.
> >
> > so the argv[] array in execve() would be loaded as:
> >
> >     argv[0]=sh, argv[1]=scriptB, argv[2]=scriptA, and
> >     argv[3...]=command line args passed to scriptA.
> >
> > i read many many execve() man pages, and it seems like this is the way
> > things might be.  but in practice, it appears on many unix's, argv[] gets
> > loaded additionally with any options given to a script (which is given as
> > the "[arg]" to the interpreter) on the 1st line of a script
> > (which seems to be the more sensible way of doing things).
> >
> > can anyone tell me if this is "proper", and why or why not?
> > there doesn't seem to be consistency across unix's.
> > a few ignore, or give an error if more than one
> > "[arg]" exists on the 1st line of a script.
> 
> The only thing I can find in IEEE Std 1003.1-2001 (aka SUSv3) is
> 
>  "If the first line of a file of shell commands starts with the
>   characters "#!", the results are unspecified."
> 
> which would indicate that there is no "proper" way of doing this.  You
> may also want to have a look at bin/16393; at the bottom is a list of
> how some unices handle the situation.  Your best bet at trying to be
> portable is to use at most one argument, no whitespace and no "#".
> 
> The PR: <http://www.freebsd.org/cgi/query-pr.cgi?pr=16393>