|Exit Code Number||Meaning||Example||Comments|
|1||catchall for general errors||let "var1 = 1/0"||miscellaneous errors, such as "divide by zero"|
|2||misuse of shell builtins, according to Bash documentation||Seldom seen, usually defaults to exit code 1|
|126||command invoked cannot execute||permission problem or command is not an executable|
|127||"command not found"||possible problem with $PATH or a typo|
|128||invalid argument to exit||exit 3.14159||exit takes only integer args in the range 0 - 255|
|128+n||fatal error signal "n"||kill -9 $PPID of script||$? returns 137 (128 + 9)|
|130||script terminated by Control-C||Control-C is fatal error signal 2, (130 = 128 + 2, see above)|
|255*||exit status out of range||exit -1||exit takes only integer args in the range 0 - 255|
According to the table, exit codes 1 - 2, 126 - 165, and 255  have special meanings, and should therefore be avoided as user-specified exit parameters. Ending a script with exit 127 would certainly cause confusion when troubleshooting (is the error a "command not found" or a user-defined one?). However, many scripts use anexit 1 as a general bailout upon error. Since exit code 1 signifies so many possible errors, this might not add any additional ambiguity, but, on the other hand, it probably would not be very informative either.
There has been an attempt to systematize exit status numbers (see /usr/include/sysexits.h), but this is intended for C and C++ programmers. A similar standard for scripting might be appropriate. The author of this document proposes restricting user-defined exit codes to the range 64 - 113 (in addition to 0, for success), to conform with the C/C++ standard. This would allot 50 valid codes, and make troubleshooting scripts more straightforward.