Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: C.R.Ritson@newcastle.ac.uk ("C.R. Ritson")
Newsgroups: comp.std.unix
Subject: Shell standardization (for c.std.unix)
Message-ID: <17011@cs.utexas.edu>
Date: 17 Jan 91 12:34:20 GMT
Sender: jsq@cs.utexas.edu
Lines: 33
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: C.R.Ritson@newcastle.ac.uk ("C.R. Ritson")

Please  could  you  post  this  to  comp.std.unix, or else reply to it
yourself if that is more appropriate.

                               -------

I  am  unsure  of the state of standardisation of the unix shells, but
hope that the standards committees would consider removing a piece  of
functionality that is becoming both irrelevant and dangerous.

I  am  thinking of the feature where, after the exec system call fails
to be able to execute a file, the shell assumes that  if  it  has  the
execute  bit  set  and is a file, then it must be a shell script.  Now
that the exec  system  call  on  most  systems  understands  the  "#!"
notation  as  a  valid  magic  number and starts the named interpretor
itself, this is no  longer  needed,  provided  this  behaviour  itself
becomes standard.

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.

Chris Ritson
--
PHONE: +44 91 222 8175              Computing Laboratory,
FAX  : +44 91 222 8232              University of Newcastle upon Tyne,
TELEX: uk+53654-UNINEW_G            UK, NE1 7RU

Volume-Number: Volume 22, Number 74