Hacker News Reader

Comment by frou_dh | Hacker News Reader

I'm happy enough with with 0 (success), 1 (failure), 2 (invoked incorrectly, i.e. invalid flags or too few arguments). But maybe other people and particularly sysadmins care more.

Only using 0 and 1, period, and not differentiating between the situations 1 and 2 is a bit too sloppy though.

View on HN

When I was designing the programmatic API for my programmer's spell checker [0], I found that it was easy to get an exit code from something else in the stack and if they all used 1, there wasn't a way to differentiate. This is the reason I went with sysexists, so I would have a more nuanced codes to reduce the probability of two processes in the stack returning confusable errors.

[0] https://github.com/crate-ci/typos

Is 2 used consistently by any programs in this manner?

If I was to advise someone I'd tell o interpret and write programs using the following rule of thumb and not to worry too much:

0 = success / true

1 = failure (read stderr) / false

>1 = failure (read stderr & docs)

The main arg parser for Rust (clap) was looking at using sysexits for usage but then got feedback from burntsushi (of ripgrep fame) for how rarely it is used and instead encouraged 2. In looking at it, it seems like 2 is the most consistent code and for clap v3 will be using it.

- 2 is "misuse of shell built-ins" for bash [1] - Python's argparse uses 2 [2]

I feel like we looked at more but can't remember which all they were

[0] https://github.com/clap-rs/clap/pull/1637#issuecomment-58103...

[1] https://tldp.org/LDP/abs/html/exitcodes.html

[2] https://github.com/python/cpython/blob/main/Lib/argparse.py#...

Many programming languages will exit 1 for unexpected exceptions at runtime (or programmer error). Eg, this Ruby program will exit 1:

    $ ruby -e 'raise StandardError.new "oops"'
    Traceback (most recent call last):
    -e:1:in `<main>': oops (StandardError)
    $ echo $?
    1

And so will this one:

    $ ruby -e 'invalid method call'
    Traceback (most recent call last):
    -e:1:in `<main>': undefined local variable or method `call' for main:Object (NameError)
    Did you mean?  caller

So, it's nice to distinguish between a possibly unexpected exceptional exit (1), and an "error case detected by the programmer", which is what I use exit (2) for.

The Linux Standard Base (LSB) specification specifies this meaning of 2 for init scripts, and systemd interprets daemon exit codes in accordance with LSB. From there, this meaning of 2 has spread to other types of programs and is quite common, but still far from ubiquitous.

https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LS...

I do something very similar, though I read I should avoid codes 1 and 2 so my error codes start at 3: https://github.com/RPGillespie6/fastcov/blob/master/fastcov....

That way automated CI pipelines (or whatever) can switch on the return code if needed rather than try to parse stderr

This is the first I'm hearing of using code 2 myself. Been using bash casually for years now.

Bash uses 1 and 2 this way.

This matches with my memories of late 80s UNIX idiom:

0, OK

1, Error

2, Bad arguments

However I'm not surprised that requirements evolved and somebody needs more structured and informative exit codes.

I remember the Jetbrains IDE's bash script used a code to mean restart the application by putting it in a loop and breaking unless it got that exit code.

I have used 75 (EX_TEMPFAIL) to ask systemd to restart a service (by adding "RestartForceExitStatus=75" to the service unit file).

Reply on news.ycombinator.com