[ On Wednesday, March 21, 2001 at 22:35:14 (-0800), Greywolf wrote: ]
> Subject: Re: a few minor cleanups to src/share/misc/style
>
> On Wed, 21 Mar 2001, Greg A. Woods wrote:
> 
> # Some failures aren't "random".  There are a few common classes of
> # errors, common enough that there are even de facto standards for exit
> # codes to represent them, the most common probably being usage errors
> # (with a corresponding exit value of 2).
> 
> Usage error == 2?  Never in my life.

You've never looked very far have you?  :-)

In fact you just posted a half-assed example yourself!  (though one
could easily confuse a non-existant file with different kind of error
related to a file that was really supposed to exist but doesn't.  GNU
grep is horribly confused about how it uses 'exit(2);' so it's not
really the best example for this.)

FYI everything I've ever written has used exit(2) to indicate a
command-line usage error, and I didn't invent that convention by a long
shot.  I don't know the history of this convention, but it goes *way*
back!

I agree with Chris though that almost no program I've ever seen or
written will check for (status == 2) as an indication of a usage error.
It's more something I'd expect to see from my wee KSH trick (something
I've also been using for over a decade now):

	trap '
	        rc=$?;
	        if ((ERRNO > 0)); then
	                EMSG="; errno: $ERRNO"
	        else
	                EMSG=""
	        fi;
	        print "${0#-}: exit code: $rc$EMSG"
	' ERR

BTW, I really get peeved at programmers who use negative numbers for
exit codes and thus expect "char" to be a signed integer by default!
GRRR!!!!  

> Usage error falls under domain of "failed to functionally meet command-line
> criteria".

Ah, no, I wouldn't agree with that.  That would tend to indicate that
such functionality was both sane and possible, but just not implemented
in the given instance of the implementation actually invoked.  I'd
probably pick "4" out of a hat to represent that kind of error.

Use of flags that don't exist, flags without their required optarg
values or vice versa, failure to specifiy a normal argument
(eg. filename) when one is required or vice versa, etc., are all "usage"
errors.

> I wish it could have been thought out a bit more (as the signal addition
> thing seemed to be) that exit codes could have been a bit larger such that
> errno was stuck in there somehow.  When something goes wrong, it'd be
> really nice not to have to parse the stderr of the program (such as in
> a script) to figure out what went wrong.

Putting errno in the exit status would be useful for the most basic of
programs, but not very useful in any more complex system, which is why
the meanings of things in <sysexits.h> don't even map to errno values.

However you're absolutely right that there's no good reason to throw
away information by reducing exit status codes from their current 8 bits
down to one bit -- if there's some reasonable de facto standard for the
meaning of exit code values then programs should try to conform and
provide that information when they exit abnormally.

> But I guess I should probably be coding, not scripting, but that's
> (*((*worm_can)())[]) another;

:-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>