Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site opus.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!seismo!ut-sally!opus!rcd
From: rcd@opus.UUCP
Newsgroups: net.unix,net.flame
Subject: Re: perror(3) considered harmful
Message-ID: <184@opus.UUCP>
Date: Sun, 4-Mar-84 05:20:08 EST
Article-I.D.: opus.184
Posted: Sun Mar  4 05:20:08 1984
Date-Received: Mon, 5-Mar-84 00:41:35 EST
References: <1061@cwruecmp.UUCP>
Organization: NBI, Boulder
Lines: 26

(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