Hacker News Reader

Comment by gdwatson | Hacker News Reader

It seems to be a Ruby equivalent to sysexits.h.[1] I don't know how widely used the codes are, but the idea is neat.

[1] https://manpage.me/index.cgi?apropos=0&q=sysexits&sektion=0&...

When I'm trying out a new language and writing programs in it that I'm going to invoke from the command line, one of the first things I do is put in those BSD-style extended error exit statuses. I also check along the way whether whatever option parsing library I'm using integrates at least EX_USAGE by default; the answer tends to be no, though I'm not sure how much of that is the library authors not knowing or intrinsically not considering them appropriate, and how much might be “new users will see this behavior, decide it looks complicated or bizarre, and leave”.

You're right. However, I'm also extending the set of exit codes with Bash recognised statuses[1]. This also includes a list of fatal signals, e.i. exit codes 128 + n, where n is a corresponding signal error.[2]

[1] http://tldp.org/LDP/abs/html/exitcodes.html [2] https://man.openbsd.org/signal.3

Meanwhile on OpenBSD[1]...

"A few programs exit with the following non-portable error codes. Do not use them."

[1] https://man.openbsd.org/sysexits

In this context "Do not use them.", these are reserved codes and shouldn't be redefined in your programs to mean something entirely different. So codes in range 64-78 are a standard across Unix systems. Usually, specific program codes are best served using codes below 64.

I have included a method that helps you check if a code is reserved or not. For example, TTY::Exit.exit_reserved?(126) will return true as this is a status used by Bash to indicate a problem with executing a command.

Reply on news.ycombinator.com