Exit code l0 is a non-sysexits compliant code

[kkirsche]

Good afternoon,

I'm writing to ask if it'd be possible to explain why the choice for an l0 exit code instead of a 0 exit code was used. Generally speaking, application exit codes are meant to be numeric, with some being specifically meant for uses based on the sysexits.h file (can be viewed via man sysexits). This specifically documents:

0   /* successful termination */
64  /* base value for error messages */
64  /* command line usage error */
65  /* data format error */
66  /* cannot open input */
67  /* addressee unknown */
68  /* host name unknown */
69  /* service unavailable */
70  /* internal software error */
71  /* system error (e.g., can't fork) */
72  /* critical OS file missing */
73  /* can't create (user) output file */
74  /* input/output error */
75  /* temp failure; user is invited to retry */
76  /* remote error in protocol */
77  /* permission denied */
78  /* configuration error */
/* maximum listed value */

I was wondering why the choice for a leading character was used instead of the more broadly accepted 0 value for a successful exit. There are other exit codes which are common, such as:

1 - Catchall for general errors
2 - Misuse of shell builtins (according to Bash documentation)
6 - No such device or address
124 - command times out
125 - if a command itself fails (based on coreutils)
126 - if command is found but cannot be invoked (e.g. is not executable)
127 - if a command cannot be found, the child process created to execute it returns that status
128 - Invalid argument to exit (exit is meant to take only integer args in the range 0 - 255)
137 - if command is sent the KILL(9) signal (128+9), the exit status of command otherwise
141 - SIGPIPE - write on a pipe with no reader
143 - command terminated by signal code 15 (128+15=143)
255* - exit status out of range.

Any additional information would be appreciated, this had triggered some issues in our CI pipeline as it looks for 0 for success (Gitlab CI) and non-zero for failures.

[alanhamlett]

It does default to zero exit code on success, and non-zero on error. The only time exit code 10 is used is when --nonzero-exit-code is present, so scripts can use the exit code when they need to know if packages were updated or not. This feature was added with #5.

[kkirsche]

Which doesn’t align with tools like black in check mode. The idea would be that even in non zero exit code you would still use 0 when no update is required. As such, why is 10 used instead when all is good and it was successful. It makes sense to return something when packages need an update but not when it ran successfully and it doesn’t have any packages to update

[alanhamlett]

Oh, got it. We can change that in a major release to exit zero when everything is up to date.

[alanhamlett]

@kichik and @pradyunsg, before we change the nonzero exit code behavior to exit with 0 instead of 10 when no packages were updated, I want to check with you first. Would 0 exit code work for you? The 11 exit code would still be used when --nonzero-exit-code present and any packages needed updating.

[pradyunsg]

I'm not sure why I've been mentioned here. I have no clue what this discussion is about. :)

[alanhamlett]

Fixed with 51074bb.

[kichik]

Sorry for the very late reply, but I just now realized why you asked me and @pradyunsg and it's because of issue #5. I no longer use pur, so the change doesn't affect me. Thanks for checking!