Email list hosting service & mailing list manager

Interpreting exit code given to "exit" procedure Lassi Kortela (14 Aug 2019 14:36 UTC)
Re: Interpreting exit code given to "exit" procedure John Cowan (14 Aug 2019 19:49 UTC)
Re: Interpreting exit code given to "exit" procedure Lassi Kortela (14 Aug 2019 20:50 UTC)
Re: Interpreting exit code given to "exit" procedure Lassi Kortela (14 Aug 2019 20:54 UTC)
Re: Interpreting exit code given to "exit" procedure John Cowan (14 Aug 2019 20:57 UTC)
Re: Interpreting exit code given to "exit" procedure Lassi Kortela (14 Aug 2019 21:10 UTC)
(missing)
Fwd: Interpreting exit code given to "exit" procedure John Cowan (14 Aug 2019 21:34 UTC)
Re: Interpreting exit code given to "exit" procedure John Cowan (14 Aug 2019 21:36 UTC)
Re: Interpreting exit code given to "exit" procedure Lassi Kortela (14 Aug 2019 21:45 UTC)
Re: Fwd: Interpreting exit code given to "exit" procedure Lassi Kortela (14 Aug 2019 21:41 UTC)
Re: Fwd: Interpreting exit code given to "exit" procedure Lassi Kortela (15 Aug 2019 06:43 UTC)

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.