* On Wednesday 2005-11-09 at 00:47:29 +0000, Julian Foad wrote:
> Charles Levert wrote:
> >
> >My take is that we could eventually change the
> >whole suppressible_error()/errseen framework,
> >but not right now, since this is more of a new
> >feature than a bug fix. This would go well with
> >my proposal to track the kind of error (i.e.,
> >which system call) with a bit-flag in the exit
> >code as well.
>
> May I gently discourage you from proposing to track the kind of error with
> a bit-flag in the exit code. See, for example,
> <http://www.delorie.com/gnu/docs/glibc/libc_559.html>.
There seems to be three issues:
-- Is it even useful?
-- Bits 0 and 1 are already used. This
reference indicates that bit 7 has a
special meaning as well. This leaves 5
bits for encoding an error. Is using bit
flags the best utilization to make of them?
Can we run out of bits before equal
opportunity has been given to every major
error condition?
-- Do many existing shell scripts use the
"test $? -eq 2" (or "test $? = 2") logic?
If so, that's a strong incentive to not
change this at all. However, encouraging
users to use the "test $? -gt 1" (or
"test $? -ge 2") logic might be a good
thing to do for portability in any case,
as this is all that POSIX mandates (for
grep, cmp, diff, and possibly others).
Should this be added to the docs?
Regardless, even if the exit status is not to
encode what went wrong, error messages can still
provide information on the specific system call
that failed for each message, but that would be a
new feature and not a bug fix, so not a priority.
