I just read that intro page. It's rather poorly written. But an accurate answer is going to take a while.
From the standpoint of a C programmer who is using the system call interface, when a program invokes exit() or _exit(), the argument to exit is anded with 0377 and the result is the exit code for the process. If a process dies as the result of a default action of a signal it will get an exit code which is non-zero but which has non of the lower 8 bits set. You're supposed to use the macros which are mentioned on wait(2) man page to portably determine the signal number. It is one or the other. Sending a signal to a process which has started the kernel portion of the exit() system call has no effect. All 8 bits are available to the programmer resulting in values 0 through 255 being legal.
And only a process that is running can invoke the exit() call. If a C program tries to run a non-existant program or one without the proper execute bits set, the exec() system call itself will fail and the program will never run.
You are asking this question in the shell programming forum, though. A programmer who writes a shell sees the above interface. But a programmer who uses a shell is at the mercy of the shell's designer.
If you type "./perderabo" you will get an error message telling you that the shell can't find the file perderabo. But most shells will also set the exit code to some non-zero number. Nothing ran, the shell either noticed that the file wasn't there via stat() or it attempted the exec() which failed. But it will set $? (or $status) anyway. This is kinda useful I guess.
The New Kornshell Command and Programming Language by Morris Bolsky and David Korn says:
Quote:
0 Normal exit.
1-125 Failure.
126 A command was found but cannot be executed.
127 A command could not be found.
128-255 Failure.
256 and above A command has exited because of reciept of a signal.
Version: With the 11/16/88 version of ksh, 129-160 indicated that a command had exited because of a signal....A command that could not be found or could not execute had a return value of 1.
So exit codes used by the shell for processes killed by signals are not fixed even within different versions of ksh, let alone across all shells.
What I do is use "exit 0" for success and "exit n" for failure where n is a small integer. I rarely go above 10 and have never reached 20. I rely on shells to be able to determine the difference between a zero exit status and a non-zero exit status. But I almost never test for different non-zero values. I will display a non-zero exit code where it can be seen by a human who can (perhaps) use it to understand what is happening.