home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: trt@mcnc.org (Tom Truscott)
-
- > Submitted-by: 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.
-
- For Freedomnet, we took this a bit further. We identify
- the binary's type and then execute it on the fastest available system.
- This saves a lot of wear and tear in our user environment
- with computers from a dozen different vendors.
- Wherever I log in my favorite commands still work.
- (Hmm, would other people have a dozen different personal "bin" directories?)
- Of course this isn't entirely wonderful: when we unplugged the last
- Gould machine some of my commands had to be recompiled.
- But it goes a long way and surely it is in the right direction.
-
- It is ironic that this NFS comment comes from the home of
- the Newcastle Connection, which is the intellectual parent
- of Freedomnet. We kept the faith, and the technical
- results have been most gratifying.
- You too can get religion: contact Thomas Warren at 1-919-541-6110
- or wtw@rti.rti.org.
-
- Tom Truscott
-
- Volume-Number: Volume 22, Number 76
-
-