🚀 go-pugleaf

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

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

Submitted-by: guy@auspex.uucp (Guy Harris)

>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.

Or checking for "#!" in general, and doing what is done in the "exec*()"
implementations of many systems (usually in the kernel, but not
necessarily so) - i.e., have the Bourne shell capable of executing C
shell scripts (for those of you who write them :-)) that begin with "#!
/bin/csh", and the C shell capable of executing Bourne shell scripts
that begin with "#! /bin/sh", etc..

I don't strongly care where it's done (although I *do* prefer having
"execl()" AND "execv()" capable of running scripts, even if it's done by
having them be wrappers around kernel traps with the wrappers checking
for the "#!" line if they get ENOEXEC), but it *would* be nice if the
system didn't inappropriately try to run files that happened to have
execute permissions as scripts if, in fact, they aren't scripts. 

I don't know if anything more should be said by any standard than simply
"we do not guarantee that any shell will execute a script that doesn't
begin with '#!'", so that you can remove the "if it gets ENOEXEC, treat
it as a script" stuff and still comply with the appropriate POSIX
standard(s).


Volume-Number: Volume 22, Number 79

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <17155@cs.utexas.edu> jack@cwi.nl (Jack Jansen) writes:
>I don't see any problem in the shell reading the first line and
>checking it for #!/bin/sh.

Shells that have done this (e.g. some csh implementations on UNIX System V)
have definitely caused problems.  For example, Most of my shell scripts
start with #!/usr/5bin/sh to ensure System V semantics on BSD systems;
however, on a genuine UNIX System V system I was expecting the script to
be interpreted by /bin/sh (even if executed by csh).  We discovered that
some overly-"helpful" implementations of csh on System V, however, went
ahead and tried to find /usr/5bin/sh, which of course made the execution
fail.

Volume-Number: Volume 22, Number 80

Submitted-by: rcd@ico.isc.com (Dick Dunn)

jack@cwi.nl (Jack Jansen) writes:

> ... 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.

While I don't really intend to wish evil upon Jansen, I do wish that people
who make statements like this would have to keep a hand in maintaining
large systems.

It is, indeed, trivial to change any given shell script by the addition of
a #! line at the beginning.  But the task of finding (all instances of) all
shell scripts and correcting them all is a most incredible nightmare.  Even
this ignores finding the programs which generate shell scripts (a much
smaller class than the former, but much harder to solve).

The alternate solution which has been suggested--having the shell sanity-
check before it executes a file--is far more practical to carry out in the
real world, and will find virtually all non-shell-script problems.
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...Mr. Natural says, "Use the right tool for the job."

Volume-Number: Volume 22, Number 83

Submitted-by: karish@mindcraft.com (Chuck Karish)

In article <17400@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) wrote:
>In article <17155@cs.utexas.edu> jack@cwi.nl (Jack Jansen) writes:
>>I don't see any problem in the shell reading the first line and
>>checking it for #!/bin/sh.
>
>Shells that have done this (e.g. some csh implementations on UNIX System V)
>have definitely caused problems.  For example, Most of my shell scripts
>start with #!/usr/5bin/sh to ensure System V semantics on BSD systems;
>however, on a genuine UNIX System V system I was expecting the script to
>be interpreted by /bin/sh (even if executed by csh).

It would seem that programmer expectations were more at fault here than
were the SysV shells.  The scripts he described were designed to
exploit a difference in the behavior of shells on different systems.  I
don't understand why it worked, though.  On some older SysV-based
systems I've used, scripts that start with the '#' character are
interpreted as csh scripts no matter what follows the '#'.

Some systems that honor "#! /bin/whatever" do not default to csh if the
file starts with just "#".

The need for a hard-coded path makes scripts that depend on the "#!"
mechanism non-portable. "/usr/5bin/sh" is the right path for a shell
with full SysV functionality on a Sun.  On a DEC system, the
incantation is "/bin/sh5"; on other systems, the correct name might be
"/usr/usg/sh" or "/bin/bsh".  Perhaps what we need is a standard set of
non-filename identifiers for shells.

Creative use of links can help alleviate this problem on existing
systems.

I would be more optimistic that the adoption of the 1003.2 standard
would solve this problem if I hadn't already seen the many different
ways that vendors have isolated 1003.1 behavior in compatibility
modes.  Operating system standards won't live up to their full
potential until they're accepted as the default interfaces.

To change the subject a little, what features of modern sh
implementations cause scripts written for the BSD sh to fail?  I
presume there's a reason that BSD vendors don't install a SysV sh in
/bin.  Followups on this point should probably go to comp.unix.shell.
-- 

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000

Volume-Number: Volume 22, Number 90

Submitted-by: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)

>>>>> On 22 Jan 91 21:28:49 GMT, guy@auspex.uucp (Guy Harris) said:

Guy> I don't strongly care where it's done (although I *do* prefer having
Guy> "execl()" AND "execv()" capable of running scripts, even if it's done by
Guy> having them be wrappers around kernel traps with the wrappers checking
Guy> for the "#!" line if they get ENOEXEC), but it *would* be nice if the
Guy> system didn't inappropriately try to run files that happened to have
Guy> execute permissions as scripts if, in fact, they aren't scripts. 

Essentially, "#!" becomes a magic number.  I would also prefer this be in
the kernal.

Invitation for discussion: If the path after the "#!" doesn't begin with
"/", "./" or "../", should PATH be searched for the execuatble?  If so, how
best could this be implemented?

The reason I bring this up is in SVr4 (OSF/1?), there have been changes in
the directory hierarchy and commands are not necessarily where they've
historically been.  Of course, all scripts that are part of the OS can (and
should!) contain absolute path names.  It would be nice for application
developers to be able to write hierarchy independent scripts.  Even nicer
would be for applications developers to be able to write their own
interpreters without caring where the user installs the interpreter (as
long as the interpreter's directory is in PATH).
--
Chuck Phillips  MS440
NCR Microelectronics 			chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO.  80525   		...uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 22, Number 107

Submitted-by: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)

>>>>> On 4 Feb 91 11:50:07 GMT, Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) said:
Chuck> Invitation for discussion: If the path after the "#!" doesn't begin
Chuck> with "/", "./" or "../", should PATH be searched for the execuatble?
Chuck> If so, how best could this be implemented?

Based on feedback from Ernest Hua (thanks!), I'd like to ammend this.  SUID
scripts under no circumstances should allow PATH searching for '#!'
arguments -- even if not SUID root.

Continuing the earlier thread, not only are directory structures
non-portable, but some interpreters (e.g. pearl, gawk, bash) have no POSIX
or otherwise defined directory location.  '#!' path searching also allows
vendors to write their own interpreters for scripts without forcing a
particular directory structure on admin.  Further, it allows different
versions of the same interpreter to be used simultaneously based on each
user's path.
--
Chuck Phillips  MS440
NCR Microelectronics 			chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO.  80525   		...uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 22, Number 123