On 21 Mar 2001, Chris G. Demetriou wrote:

# > The other thing is what if you need to denote different conditions
# > via different exit stats (as in success, failure-because-of-runtime-
# > criteria-mismatch, failure-because-of-resource-unavailability)?
# > i.e., what if it's possible for something to fail in several different
# > ways?  I think it'd be the polite thing to do to provide (and document)
# > several different exit codes.
#
# That's been "prohibited" by KNF forever.

Does KNF apply to userland or kernel only?  If the latter, okay, I can see
what you might do in the deep true-or-falses of the lower levels.  If it
applies to userland, well, I can think of good reasons for it.

"grep" comes to mind:
	- if it succeeds in doing what was requested on the command line,
	  it exits with 0.

	- if it fails the command line criteria because there was no
	  matching data, it exits with 1.

	- if it fails because the file wasn't there in the first place,
	  it exits with 2.

Oh, yes, and "fsck" (otherwise rc(.d/fsck) wouldn't be able to
differentiate between its various troubles and required actions).

"0" and "1" just don't cut it all the time, and trying to parse the
error message that's spit out can be a large satanic female canine.

# As with many things, if there's a good, strong reason to do otherwise,
# then it's reasonable.  But for random failures of a program, there's
# no great reason to differentiate.

I hardly think that the difference between "failed on criteria on input" and
"failed to find the input at all due to a resource failure" could hardly
be considered "random".

# cgd

				--*greywolf;
--
*BSD: Beyond Windows