perror(3) considered harmful

[Guy Harris]

> The fact that the kernel handles "#!" in a shell script is a major blunder.
> The kernel has no business opening shell scripts and poking around in them.
> It costs a bunch of kernel code (expensive non-pagable, non-swappable memory
> on almost all UN*CES) to do this dubious optimization, and the result is that
> the error conditions are discovered in a place where there's no reasonable
> way to handle them.  What happens is that the kernel discovers that it has
> found a semantic error in a command file.  Why should the kernel know
> ANYthing about the semantics of command files?  Leave it to a program (say,
> csh or sh, radical suggestion!) to parse command files.

Well, it's not actually *that* much extra code; I pulled the code out, tweaked
it to compile independently, and it came to 236 bytes on our VAX-11.  Doing this
a lot mounts up, but it's not a gigantic amount.  It's already been pointed out
that the kernel *already* has to open up executable files and poke around in
them, and it *does* have to know something about the format of executable files
already (i.e., the executable file header in A.OUT(5) must be known to the
kernel).  The kernel *doesn't* parse much of the command file at all; it knows
nothing about the semantics of "sh" or "csh" or "awk" or ... files, just
about the semantics of the "#!" header.  And I suspect the original intent
was not to provide an optimization; it was to generalize the notion of
"executable file" and provide services such as set-UID behavior to programs
written in interpretive languages such as "sh", "csh", and "awk" (note the
"awk"; it's not just a hack for shell files).

Besides, you'd probably be *very* surprised to know whose idea it was...
Given its relative simplicity and its generalization of the concept of
"executable file", I'd say it was somewhat in the spirit of the creators
of UNIX.  Admittedly, I don't use it much, but I don't think it's a bad
idea.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy