svn commit: r252672 - head/sbin/nvmecontrol
jilles at stack.nl
Sat Jul 6 19:51:23 UTC 2013
On Sat, Jul 06, 2013 at 08:42:49PM +0200, Pawel Jakub Dawidek wrote:
> On Thu, Jul 04, 2013 at 11:44:28AM +1000, Bruce Evans wrote:
> > Many style bugs are visible in this patch:
> > - sysexits.h is used
> Bruce, until sysexits(3) doesn't explicitly say it shouldn't be used,
> please stop calling this a bug, because you are just confusing people.
> At this point sysexits(3) actually even suggests it is blessed by
> style(9). This is how it starts:
> According to style(9), it is not a good practice to call exit(3)
> with arbitrary values to indicate a failure condition when
> ending a program. Instead, the pre-defined exit codes from
> sysexits should be used, so the caller of the process can get a
> rough estimation about the failure class without looking up the
> source code.
> In my personal opinion it doesn't hurt to use sysexits(3) - if you don't
> want to interpret exit status then treat every value != 0 as an error.
> In HAST (IIRC) I do interpret exit status - if I get EX_TEMPFAIL, I know
> I can try to restart the process, if I get something else I don't
> restart it, as I risk an infinite loop.
> Apart from my personal opinion, if you want to call it a bug and not
> confuse people, then start discussion and change the manual page to
> recommend avoiding sysexits(3). As of now we are just sending mixed
> signals and create confusion.
This is indeed confusing, because style(9) itself does not recommend
sysexits at all. This was changed in 2008 but sysexits(3) was not
adjusted along with that.
The text in style(9) that only allows 0 or 1 is not universally valid
either. Firstly, in some application areas like mail delivery, it is
conventional and documented to use and interpret sysexits codes. (So if
HAST uses sysexits, it should document that fact.) Secondly, some other
utilities such as test, cmp and diff use 0 for a "true" condition, 1 for
a "false" condition and greater than 1 (usually 2) for failures.
More information about the svn-src-head