Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site sequent.UUCP
Path: utzoo!watmath!clyde!akgua!mcnc!decvax!ucbvax!ucbcad!tektronix!ogcvax!sequent!merlyn
From: merlyn@sequent.UUCP
Newsgroups: net.unix-wizards
Subject: Re: magic numbers
Message-ID: <418@sequent.UUCP>
Date: Fri, 9-Mar-84 12:57:32 EST
Article-I.D.: sequent.418
Posted: Fri Mar  9 12:57:32 1984
Date-Received: Thu, 15-Mar-84 07:24:01 EST
References: <2639@alice.UUCP> <199@opus.UUCP>
Organization: Sequent Computer Systems, Portland
Lines: 35

[from nbires!rcd...]

[[ There's a lot of code in the Berkeley kernels to handle shell scripts -
[[ take a look at it.  Since (1) the number of applications which need to do
[[ exec's of arbitrary programs is relatively small, (2) the cost of handling
[[ scripts in user code is small compared to the rest of the fork/exec/start-
[[ up-a-shell overhead, and (3) the shell-script handling can be reasonably
[[ put in the library code where it is pageable, it seems that it would be
[[ better off there, particularly if you're at all tight on memory.  I will
[[ also (re)state my opinion that the kernel is in a bad place (at least
[[ awkward) for giving a good interpretation of errors in being unable to
[[ "exec" a shell script - it would take STILL MORE precious kernel space for
[[ the code to generate good error values, as well as yet more expansion of
[[ the set of errno values.
[[ -- 

The shell script code CANNOT be put into a library for certain cases.
The one I think of is that you cannot then have execute-only shell
scripts.  The kernel MUST open the file, and make it stdin to the
designated program.  Arbitrary interpreters (ala /bin/sh) would not
have enough power to open the file (if read-denied) and start up the
desired other interpreter.  Setuid interpreted scripts also become
available as well (such as an execute-only, read-protected, setuid
cshell script).  This is also something that couldn't be done at the
application level, but rather at the kernel level.  I thank Berkeley
for putting in this feature, and appreciate it (and use it) quite
regularly.

Randal L. Schwartz, esq.
Sequent Computer Systems, Inc.
UUCP: ...!tektronix!ogcvax!sequent!merlyn
BELL: (503)626-5700

P.S. It's true... the infamous UUCP-breaker from last year is back!
After 10 months of VMS, I get to play with UNIX again!  What a deal.