Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site cwruecmp.UUCP Path: utzoo!linus!vaxine!wjh12!genrad!decvax!cwruecmp!decot From: decot@cwruecmp.UUCP (Dave Decot) Newsgroups: net.unix,net.flame Subject: Re: perror(3) considered harmful Message-ID: <1073@cwruecmp.UUCP> Date: Sun, 4-Mar-84 16:27:42 EST Article-I.D.: cwruecmp.1073 Posted: Sun Mar 4 16:27:42 1984 Date-Received: Mon, 5-Mar-84 04:06:30 EST References: <1061@cwruecmp.UUCP>, <184@opus.UUCP> Organization: CWRU Computer Engr. Cleveland, Ohio Lines: 37 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@rand-relay)