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