Guidelines for Setting Exit Status Codes
Providing a descriptive error message for stderr is fine and good for interactive users, but if you expect your scripts to be used by other scripts / programs, you should have distinctive error codes for different failures, so calling the script can make an informed decision about how to deal with rejection.
If the caller is unwilling to handle different failures differently, it can always check the return code for > 0
- but don't assume it does.
source to share
There are several guidelines, see wikipedia, but not normative, other than one of 0 iff success:
http://en.wikipedia.org/wiki/Exit_status#POSIX
* On Unix and other POSIX-compliant systems, the wait system call sets the state to an int, packed as a bit, with various types of information about the termination of the child process. If the child terminated by exiting (as defined by the WIFEXITED macro, the usual case is that it died from an uncaught signal), SUS indicates that 8-bit 8-bit exit states can be retrieved from the state value using the WEXITSTATUS macro in wait. h; [6] [7] When using the POSIX waitid system call (added since POSIX-2001), the status range is no longer limited and can be in the full integer range.
POSIX-compliant systems generally use the convention of zero for success and non-zero for error. [8] Several conventions have developed regarding the relative meanings of various error codes; for example, GNU recommends that codes with a high set of bits be reserved for serious bugs, [3] and FreeBSD has documented a wide range of preferred interpretations. [9] Values for 15 status codes 64 through 78 are defined in sysexits.h. They are historically derived from sendmail and other messaging agents, but they have since found use in many other programs. [ten] *
source to share