Shell standardization (for c.std.unix)

[Jack Jansen]

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