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.