Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP Path: utzoo!linus!decvax!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix,net.lang.c Subject: Re: 'exit(1);' considered useless (slight flame) Message-ID: <1663@rlgvax.UUCP> Date: Sun, 5-Feb-84 19:39:08 EST Article-I.D.: rlgvax.1663 Posted: Sun Feb 5 19:39:08 1984 Date-Received: Thu, 9-Feb-84 03:37:40 EST References: <957@proper.UUCP>, <232@hou3c.UUCP> <968@proper.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 35 > However, why shouldn't errno be used as an exit status indicator? > At least within Unix-variants, those values are quite specific, and > readily looked up in the manuals. Because, to put it bluntly, there is *not* a one-to-one correspondence between UNIX system call errors and command errors. What's the exit status for a syntax error in the command line? There's no ECMDSYNTAX in... > And, as I implied in my original article, why not more use of perror(3)? > I find error messages such as: > "can't open file" > are frustratingly trite (and all too common), when one could have easily > used perror(3) to produce more meaningful messages as: > ...(and of course, including the name of the file in the error message > would be nice). I agree that "can't open file" isn't informative enough (UNIX isn't the only sinner here, though; RSX-11M error messages also just say "sorry, couldn't do it"), but one reason may be that it's a pain in the *ss to get "perror" to say: frob: /etc/mumble: No such file or directory Neither perror("frob") nor perror(filename) do what you really want (and for the "link" system call, you usually want to print *both* names, which "perror" won't let you). The answer is to use "sys_errlist" and use "fprintf" (not "printf", please, don't send error messages to stdout!) to print the message. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy