Exit statuses and errors messages (was Re: grep . /; echo $?)

[Charles Levert]

* 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.