Shell standardization (for c.std.unix)

[Tom Truscott]

Submitted-by: trt at mcnc.org (Tom Truscott)

> Submitted-by: 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.

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 at rti.rti.org.

	Tom Truscott

Volume-Number: Volume 22, Number 76