magic numbers

[merlyn at sequent.UUCP]

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