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