home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: jack@cwi.nl (Jack Jansen)
-
- > = trt@mcnc.org (Tom Truscott) writes:
- >> = C.R.Ritson@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@cwi.nl
- dan dooft het licht | Uucp: hp4nl!cwi.nl!jack
-
-
- Volume-Number: Volume 22, Number 78
-
-