perror(3) considered harmful

[Dave Decot]

    D	Command "foo" gives message "foo: command not found" when foo
    A	is executable because the first line of foo says
    V
    E	     #! csh -f

    D	and "csh" is not a full pathname so exec*(2) can't find it.
    E	What I want to know is, why in blazes doesn't somebody tell me that 
    C	*csh* is the "Command not found" and not my innocent (at least "found")
    O	shell file?
    T
    .	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.

I, Dave Decot, *agree* with most everything you say.  The kernel HAS, however,
gotten into the business of setting a variable indicating a vague "error
status code" that is intended to be used by calls to perror().  I don't
think this is wise, unless the codes can be made more descriptive and
unambiguous.  By the way, the kernel already has to look for the "magic number"
at the beginning of executables that distinguishes binary programs from
shell files, anyway.  That's probably why they extended the idea to "well,
ok, csh is just another variety of "program" executors, so exec(2) should
make that differentiation, too."

Dave Decot		 "Yet another victim of YASEM."
decvax!cwruecmp!decot    (Decot.Case at rand-relay)