Shell standardization (for c.std.unix)
Jack Jansen
jack at cwi.nl
Mon Jan 21 21:33:48 AEST 1991
Submitted-by: jack at cwi.nl (Jack Jansen)
> = trt at mcnc.org (Tom Truscott) writes:
>> = C.R.Ritson at newcastle.ac.uk ("C.R. Ritson")
>> The danger of direct interpretation by the shell is that the file is
>> quite likely to be an executable object file for some other
>> architecture seen from the wrong side of an NFS mount. When this is
>> the case the shell produces large numbers of "not found" messages and
>> often ends up resetting numerous operating modes. Our newer users
>> find this most confusing.
>If the kernel simply returned EACCES (for example) rather than ENOEXEC
>when the file is non-ascii, the shells would not attempt interpretation.
>(Just check that the first 4 characters have value > 1 and < 128.)
>Dropping direct interpretation does make good sense.
>But there is the problem of old kernels (e.g. System V.3.2!!) lacking #!,
>and I think a surprising number of scripts will stop working
>(such as /bin/true on some systems). Serves them right I suppose.
I think you've missed the point here. The question is not wether the
kernel recognizes #!, but wether the shell recognizes it.
Currently, when the kernel returns ENOEXEC the shell just blindly assumes
that we have a shell script here and starts executing it. I don't see
any problem in the shell reading the first line and checking it for
#!/bin/sh.
The only thing that this would break is that old shell scripts without
a #! first line wouldn't execute anymore, but this is trivial to fix
by adding the #! line.
--
--
Een volk dat voor tirannen zwicht | Oral: Jack Jansen
zal meer dan lijf en goed verliezen | Internet: jack at cwi.nl
dan dooft het licht | Uucp: hp4nl!cwi.nl!jack
Volume-Number: Volume 22, Number 78
More information about the Comp.std.unix
mailing list