this does seem to be an ambiguous area.
it seems more sane to allow arguments
to a script given to an interpreter on the
shebang line, passing everything after
"#!/interpreter [arg]" off for
"eval" or "sh -c" type parsing.
i don't know how it breaks anything to load execve's argv[]
with everything after the shebang, followed by command line
options/args. but it sure muddies the water if you don't.
otherwise there 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 currently not ok, but why shouldn't it be?
#!/bin/sh -c "string" this is currently not ok, but why shouldn't it be?
#!/bin/sh script this is obviously ok.
#!/bin/sh -n script this is currently not ok, but why shouldn't it be?
#!/bin/sh script 1 2 this is ok with FBSD and RH Linux,
but not ok in a few implementations,
but why shouldn't it be?
it seems that only a minority of execve() man pages / implementations
are preventing the sane solution ...
> 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>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
