Re: style, sysexits(3), and man RETURN VALUES for sys programs

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Rhialto pointed me to sysexits(3) that was exactly what I was
>> looking for (for inetd(8) revision). So kudos to him!
> I deliberately didn't mention sysexits.h (or sysexits(3)) as I don't
> think it is really appropriate here.

I agree and I disagree.

I agree that it certainly isn't the same sort of compelling use case
that sendmail was back in the day.

But, also, just beacuse you or I can't think of a use case for it
immediately doesn't mean one won't appear.  And, as far as I can see,
it does no harm.

The rc script might even be able to use it; that it doesn't now could
mean nothing more than that there has historically been no such
information for it to use, so why try?  Certainly I can see a boot-time
script caring about, for example, the difference between EX_CONFIG
(fall back to a minimal configuration) versus EX_SOFTWARE (give up),
possibly even retrying a few times in case of EX_TEMPFAIL.

> Without that, all the calling program sees is "program exited with
> status 78" so something went wrong, but what?  Having to go back to
> the manual (or system include file, which would be worse) to find out
> what that error number means, is horrid - that's the way systems used
> to work in the dark ages, when actually putting error messages, as
> strings, in programs was too costly - and believe me, you don't want
> to be in that environment.

exit(EX_CONFIG) is no less informative than exit(1), for sure.
Certainly, producing a message is good, but, if it's easy to do (which
it appears to be, here), producing a message and exiting with a
sysexits exit code is better.  As a putative script writer, I'd far
rather use a sysexits exit code than have to try to scrape stderr.

> If there's also a message that explains the error, then you don't
> need much in the way of specifics in the exit status, as all anyone
> will look at is the error message [...]

All any _human_ will, perhaps.  Maybe _you_ are confdient nobody will
ever want a script to take differential action based on the failure
class; _I_ am not.

> Unless there is a really good reason - which would amount to there
> actually being something which will interpret the exit status from
> inetd for more that ok/not ok then I wouldn't be going near sysexits.

I would say that, if it's easy to produce a useful exit code, why not?
It's no less informative than single-bit exit code; if a script just
cares about success/failure, then sysexits exit codes work exactly as
well as exit(1), and they do make a little more information available
in case anyone wants to build a script that uses it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B