> Either exit with 0 or 1. If you don’t have a strong reason to use more at this point, then don’t. Instead provide users a good, parseable error or a warning message on stderr.
Please don't. There is literally no upside in having all exit codes be 1. Use all the numbers! 1 for other/generic, 2 for invalid argument, 3 for partial success, 4 for server down, 19 for unparseable data... Just make sure to document them, and don't change meaning of existing code too much.
Any program/script which does not care treats all non-zero exit codes identically. But a more advanced user can look at exit code and do something, because checking exit code is easier than capturing and parsing stderr.
(There are few conventions - 1 is generic failure, 2 is often invalid arguments, 110+ are associated with shell. But 3-100 range is fair game for apps)
> Either exit with 0 or 1. If you don’t have a strong reason to use more at this point, then don’t. Instead provide users a good, parseable error or a warning message on stderr.
Please don't. There is literally no upside in having all exit codes be 1. Use all the numbers! 1 for other/generic, 2 for invalid argument, 3 for partial success, 4 for server down, 19 for unparseable data... Just make sure to document them, and don't change meaning of existing code too much.
Any program/script which does not care treats all non-zero exit codes identically. But a more advanced user can look at exit code and do something, because checking exit code is easier than capturing and parsing stderr.
(There are few conventions - 1 is generic failure, 2 is often invalid arguments, 110+ are associated with shell. But 3-100 range is fair game for apps)