perror(3) considered harmful

[rcd at opus.UUCP]

(Re:  command "foo" gives message "foo: command not found" when foo is
executable)
 > Because the first line of foo says
 >     #! csh -f
 > And, of course, "csh" is not a full pathname (why does it have to be!?),
 > so poor exec*(2) can't find it.
 > 
 > What I want to know is, why in blazes doesn't somebody tell me that 
 > *csh* is the "Command not found" and not my innocent (at least "found")
 > shell file?
...and later...
 > If the kernel can't give more accurate messages, perror shouldn't be used.

The kernel ISN'T IN THE BUSINESS OF GIVING "ERROR MESSAGES"!  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.

Yours for making kernels be kernels again...
{hao,ucbvax,allegra}!nbires!rcd