Re: Fwd: Interpreting exit code given to "exit" procedure
Lassi Kortela 15 Aug 2019 06:43 UTC
> I thought the safe portable maximum was 126 [or 127]
>
> The exit and wait procedures support 0-255, no problem. However, when a
> process running in the shell dies on a signal, the variable $? is set to
> 128 plus the signal number.
That's where my doubt came from. I think we should support 0..255 but
add a note to the SRFI text about the shell's mapping of 128+.
> This only affects shell scripts that actually examine $?. In 30+ years
> of shell programming I have never done so that I can remember.
It's should not be that uncommon. E.g. most uses of things like "grep
-q" in the shell are subtly incorrect because they don't differentiate
between "no matches found" (code 1) and an error (code 2+). UpScheme
will have a boolean command wrapper that automatically takes care of
this, so (grep "whatever") returns #t on exit code 0, #f on exit code 1
and raises an error on 2+.
> I think exit code 1 ("catchall for general errors") is the right mapping
> for #f.
It may be. #t and #f suggest a boolean pair, and anyway, 1 is a
non-successful exit code.
> (On Plan 9 Chibi translates #f to "chibi error" and #t to "".)
Cool that it runs on Plan 9 :) So it's a good codebase to mine for
portability tricks then.