magic numbers

[rcd at opus.UUCP]

<>
 > opus!rcd complains that the kernel has no business looking for the #!.
 > apparently, he doesn't understand that #! is a magic number, just like
 > 0407 or 0413.  the string that is exec'ed is inside the header that the
 > kernel must read (note: must read; so much for 'no business opening' files)
 > to determine that the file is a binary and exec it.

Yes, the kernel has to open the file to look at the magic number and get
the header, etc.  However, it need not recognize a 020443 ("#!") magic
number as valid - that was really my point.  In the "old way", the kernel
would just fail an attempt to exec a shell script and the exec library code
in the process would pick up from there.  (This is just why the ENOEXEC
error code has the meaning it does.)  Exec(2) could be made to look for a
"#!" line and handle it appropriately.  This seems a little clunky perhaps,
but remember that the kernel just opened the file and read the start of it,
so the library code probably isn't going to generate any disk accesses when
it reopens the file to look again.

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

{hao,ucbvax,allegra}!nbires!rcd