From owner-freebsd-questions Sun Feb 9 17:17:45 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F19E037B401 for ; Sun, 9 Feb 2003 17:17:41 -0800 (PST) Received: from groggy.anc.acsalaska.net (groggy.anc.acsalaska.net [208.151.119.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id C814543F3F for ; Sun, 9 Feb 2003 17:17:33 -0800 (PST) (envelope-from abc@anchorageinternet.org) Received: from en26.groggy.anc.acsalaska.net (root@printer [192.168.0.26]) by groggy.anc.acsalaska.net (8.12.6/8.12.6) with ESMTP id h1A1HQ7X038584 for ; Sun, 9 Feb 2003 16:17:26 -0900 (AKST) (envelope-from abc@anchorageinternet.org) Received: (from abc@localhost) by en26.groggy.anc.acsalaska.net (8.12.6/8.12.6) id h1A1I3bm021762 for "freebsd-questions" ; Mon, 10 Feb 2003 01:18:03 GMT (envelope-from abc@anchorageinternet.org) Date: Mon, 10 Feb 2003 01:18:03 GMT From: abc@anchorageinternet.org Message-Id: <200302100118.h1A1I3bm021762@en26.groggy.anc.acsalaska.net> X-Authentication-Warning: en26.groggy.anc.acsalaska.net: abc set sender to abc@anchorageinternet.org using -f Subject: Re: #!/bin/sh & execve X-Mailer: Umail v2.9.2 To: "freebsd-questions" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > 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. the method used by FBSD 2.2.7 seems the most sane to me, where execve's argv[] is loaded by each whitespace seperated element after the shebang, then by command line options. 1. it is flexible. 2. it functions intuitively. 3. i don't think it breaks less flexible methods. i thank you very much for explaining this to me. > 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 agree. my main problem, which doesn't exist with FBSD (thankfully), was, for example, scriptA ------- #!/bin/sh ./scriptB 1 2 3 where scriptB runs (with options), then processes scriptA, then exec's scriptA with a modified command line. (it would've been a long chore to write scriptB in C code, and it would've been a "kludge" to run scriptB on the command line with scriptA as an argument - forcing one to always type 2 words to do one command). many OS's do not allow this since they load "./scriptB 1 2 3" into a single argv[] element, which, of course, the interpreter cannot run. which seemed very stupid to me. i saw problems and limitations, and no benefit to that solution. > 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. heh - yes - i agree. i was afraid someone would pick apart all this! i didn't really take the time to study the functionality of the sh(1) options. i only meant to show the unintuitive nature of the implimentations with regard to parsing. > > #!/bin/sh script this is obviously ok. > > #!/bin/sh > . script this won't work if "script" is going to do something before exec'ing the file itself. it will end up being infinitely recursive. and similarly for the following: > > #!/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 > 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 :-) yes - i agree. i think freebsd hackers are the best. and have the best design/implementation philosophies. i am always humbled in their presence. > - Giorgos thank you. Freebsd seems to be the only intelligent OS. 2.2.7, imho, seems to be "correct". it may not "follow", but sometimes intelligence has to lead ... I would be interested in anyone could tell me how/why any of the other solutions are "more intelligent/practical". It is my personal observation the solutions of most vendors is due to SysV's limiting definition of execve(2). But I did note that Posix/SUSv3 definitions remove such arbitrary limitations (the single [arg]). #!/tmp/interp -a -b -c #d e Solaris 8: args: "/tmp/interp" "-a" "/tmp/x2" Tru64 4.0: args: "interp" "-a -b -c #d e" "/tmp/x2" *FreeBSD 2.2.7: args: "/tmp/interp" "-a" "-b" "-c" "#d" "e" "/tmp/x2" FreeBSD 4.0: args: "/tmp/interp" "-a" "-b" "-c" "/tmp/x2" Linux 2.4.12: args: "/tmp/interp" "-a -b -c #d e" "/tmp/x2" Linux 2.2.19: args: "interp" "-a -b -c #d e" "/tmp/x2" Irix 6.5: args: "/tmp/interp" "-a -b -c #d e" "/tmp/x2" HPUX 11.00: args: "/tmp/x2" "-a -b -c #d e" "/tmp/x2" AIX 4.3: args: "interp" "-a -b -c #d e" "/tmp/x2" Mac OX X: args: "interp" "-a -b -c #d e" "/tmp/x2" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message