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