tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: style, sysexits(3), and man RETURN VALUES for sys programs
>> 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
Home |
Main Index |
Thread Index |
Old Index