Subject: Re: a few minor cleanups to src/share/misc/style
To: Greywolf <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 03/21/2001 23:28:53
Greywolf <email@example.com> writes:
> Does KNF apply to userland or kernel only?
given that the notion of 'exit' and 'getopt' have no real application
in the kernel at all, i'll let you guess.
> "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.
OK, that's one example. it's also externally maintained code, and,
apparently even a documented differece.
this seems a good place to use another convention.
> Oh, yes, and "fsck" (otherwise rc(.d/fsck) wouldn't be able to
> differentiate between its various troubles and required actions).
yes, already gone over that.
> "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.
but, like it or not, that's what the style guid said to do before.
the issue is changing "0" and "1" to something both more meaningful
and standard, in that guide.
i'm not going to even think of suggesting that everybody Do Something
Better, when it has no measurable benefit. In particular, except in a
few defined cases, you can't portably assume anything other than
'success' and 'failure'.
Perhaps if somebody made a consistent effort to do better ... 20 years
ago, doing different now would make a difference. but they didn't,
and so no matter what we decide to do, it won't make a difference in
terms of portability or what other UN*Xes do. So, really, except in
the few cases where the behaviour is known and well-defined, anything
more complex will simply be more complex.
> 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".
for 99% of commands, for the scripts that invoke them, there's no real
except in a very few cases, you can't reasonably make a decision based
on exit code, let alone do so in a way that's portable.