Date: Mon, 10 Feb 2003 01:18:03 GMT From: abc@anchorageinternet.org To: "freebsd-questions" <questions@freebsd.org> Subject: Re: #!/bin/sh & execve Message-ID: <200302100118.h1A1I3bm021762@en26.groggy.anc.acsalaska.net>
index | next in thread | raw e-mail
> > 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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302100118.h1A1I3bm021762>