>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B