Date: Sun, 9 Feb 2003 21:22:08 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: abc@anchorageinternet.org Cc: freebsd-questions <questions@FreeBSD.org> Subject: Re: #!/bin/sh & execve Message-ID: <20030209192207.GA85494@gothmog.gr> In-Reply-To: <200302082158.h18LwbM9034701@en26.groggy.anc.acsalaska.net> References: <200302082158.h18LwbM9034701@en26.groggy.anc.acsalaska.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-02-08 21:58, abc@anchorageinternet.org wrote: > 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. This is something that can be bth good and bad though. As you have pointed out, if a limited sort of parsing is allowed, then it would most likely have to be sh(1)-like. This means that the mechanism that inteprets '#!' would have to know all the intricacies of the sh(1) parser to work correctly in all cases. Incomplete sh(1)-like parsers that would understand "most of the sh(1) shell syntax" would be exactly that... incomplete. Another bad thing about this is that you would then need a lot more memory to handle things like: #!/bin/sh -c \ 'my-magic-script.sh arg1 arg2 \ arg3 ...' \ `backquoted command` I'm not objecting to something like this. If you happen to roll patches for the kernel that can make it work, I'll probably try them too. But are the benefits of writing something like this worth the time required to write and test it? > 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. There is one portable way. It's easy to remember too: #!/bin/sh No spaces, no args. It works so far on all the systems I've tried. > #!/bin/sh -x this is obviously ok. #!/bin/sh set -x [...] > #!/bin/sh -vx this is obviously ok too. Similarly. > #!/bin/sh -c"string" this is currently not ok, but why shouldn't it be? #!/bin/sh exec "string" exit 1 > #!/bin/sh -c "string" this is currently not ok, but why shouldn't it be? Similarly. > #!/bin/sh script this is obviously ok. #!/bin/sh . script > #!/bin/sh -n script this is currently not ok, but why shouldn't it be? #!/bin/sh exec /bin/sh -n script > #!/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? #!/bin/sh exec /bin/sh script 1 2 > it seems that only a minority of execve() man pages / > implementations are preventing the sane solution ... The only objection I have in making execve() behave as if the whole she-bang thing was a valid sh(1) command, is that "I don't want sh(1) being imported into the kernel tree, period." Of course, what I want is irrelevant if someone comes up with a solution to the problem of having an sh(1)-like parser without having sh(1) in the kernel :-) - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030209192207.GA85494>