I'm not totally sure what the point of this is. This is advertised as exit codes "for humans and machines", however
* humans will always get way more information from a readable error message printed to stderr before exiting
* machines do not care about error details from third-party tools, apart from whether they are an input error (which can be blamed on the user, if they provided said input) or an internal error (including usage error) which is a bug and should be fixed by the calling program's developer
Indeed, the README has a lot of examples of using it in your child program, to report error, but no example of a parent program dealing with the reported error.
When I write a program that consumes output from other programs, I’ve never complained about them having meaningful exit codes rather than just returning 1 on every error. And I can use libraries like this for the consumption side, not just for production of errors.
* It includes default user-friendly error messages for all the built-in exit codes. For example, the code 64 will print " "ERROR(64): Command line usage error" to stderr.
* Machines, e.i. programs that, for example, watch over an executable can decided based on the error code what to do. If the program is interrupted by Ctrl-C then the parent program can handle the situation gracefully.
I totally agree that an example of using an exit code in a parent program would be beneficial.
* humans will always get way more information from a readable error message printed to stderr before exiting
* machines do not care about error details from third-party tools, apart from whether they are an input error (which can be blamed on the user, if they provided said input) or an internal error (including usage error) which is a bug and should be fixed by the calling program's developer
Indeed, the README has a lot of examples of using it in your child program, to report error, but no example of a parent program dealing with the reported error.