GeezerVison

In AmigaOS, MorphOS and AROS, four levels are defined:

1. OK 0
2. WARN 5
3. ERROR 10
4. FAILURE 20

Shell scripts typically execute commands and capture their exit statuses.

For the shell's purposes, a command which exits with a zero exit status has succeeded. A nonzero exit status indicates failure. This seemingly counter-intuitive scheme is used so there is one well-defined way to indicate success and a variety of ways to indicate various failure modes. When a command is terminated by a signal whose number is N, a shell sets the variable $? to a value greater than 128. Most shells use 128+N, while ksh93 uses 256+N.

If a command is not found, the shell should return a status of 127. If a command is found but is not executable, the return status should be 126.^[2] Note that this is not the case for all shells.

If a command fails because of an error during expansion or redirection, the exit status is greater than zero.

The C and C++ programming languages allow programs exiting or returning from the main function to signal success or failure by returning an integer, or returning the macros EXIT_SUCCESS and EXIT_FAILURE. On Unix-like systems these are equal to 0 and 1 respectively.^[3] A C program may also use the exit() function specifying the integer status or exit macro as the first parameter, which halts the program.

The return value from main is passed to the exit function, which for values zero, EXIT_SUCCESS or EXIT_FAILURE may translate it to "an implementation defined form" of successful termination or unsuccessful termination.

Apart from 0 and the macros EXIT_SUCCESS and EXIT_FAILURE, the C standard does not define the meaning of return codes. Rules for the use of return codes vary on different platforms (see the platform-specific sections).

In C#, the Main() method typically does not return a type (its type is void, or if async, it is System.Threading.Tasks.Task). However, Main() may indicate a return type, of type int, which is returned to the operating system. If the Main() method is declared async, then it instead returns System.Threading.Tasks.Task<int>.^[4]

In DOS terminology, an errorlevel is an integer exit code returned by an executable program or subroutine. Errorlevels typically range from 0 to 255.^[5][6][7][8] In DOS there are only 256 error codes available, but DR DOS 6.0 and higher support 16-bit error codes at least in CONFIG.SYS.^[7] With 4DOS and DR-DOS COMMAND.COM, exit codes (in batchjobs) can be set by EXIT n^[7] and (in CONFIG.SYS) through ERROR=n.^[7]

Exit statuses are often captured by batch programs through IF ERRORLEVEL commands.^[5][7] Multiuser DOS supports a reserved environment variable %ERRORLVL% which gets automatically updated on return from applications. COMMAND.COM under DR-DOS 7.02 and higher supports a similar pseudo-environment variable %ERRORLVL% as well as %ERRORLEVEL%. In CONFIG.SYS, DR DOS 6.0 and higher supports ONERROR to test the load status and return code of device drivers and the exit code of programs.^[7]

In Java, the main() does not indicate an exit code, so if needed, an exit code is manually specified through java.lang.System::exit(), which terminates the program and the JVM. Any method may call System.exit(), unless a security manager does not permit it. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.^[9]

In OpenVMS, success is indicated by odd values and failure by even values. The value is a 32-bit integer with sub-fields: control bits, facility number, message number and severity. Severity values are divided between success (Success, Informational) and failure (Warning, Error, Fatal).^[10]

In Plan 9's C, exit status is indicated by a string passed to the exits() function, and function main() is type void.

In Unix and other POSIX-compatible systems, the parent process can retrieve the exit status of a child process using the wait() family of system calls defined in POSIX header <wait.h>.^[11] Of these, the waitid()^[12] call retrieves the full exit status, but the older wait() and waitpid()^[13] calls retrieve only the least significant 8 bits of the exit status.

The wait() and waitpid() interfaces set a status value of type int packed as a bitfield with various types of child termination information. If the child terminated by exiting (as determined by the WIFEXITED() macro; the usual alternative being that it died from an uncaught signal), SUS specifies that the low-order 8 bits of the exit status can be retrieved from the status value using the WEXITSTATUS() macro.

In the waitid() system call (added with SUSv1), the child exit status and other information are no longer in a bitfield but in the structure of type siginfo_t.^[14]

POSIX-compatible systems typically use a convention of zero for success and nonzero for error.^[15] Some conventions have developed as to the relative meanings of various error codes; for example GNU recommend that codes with the high bit set be reserved for serious errors.^[3]

BSD-derived OS's have defined an extensive set of preferred interpretations: Meanings for 15 status codes 64 through 78 are defined in POSIX header <sysexits.h>.^[16] These historically derive from sendmail and other message transfer agents, but they have since found use in many other programs.^[17] It has been deprecated and its use is discouraged.^[16]

The Advanced Bash-Scripting Guide has some information on the meaning of non-0 exit status codes.^[18]

In Rust, main() may return any type that implements the trait std::process::Termination.^[19]

Internally on the Rust runtime, these will return libc::EXIT_SUCCESS upon successful execution and libc::EXIT_FAILURE upon failure.

In the Rust standard library, the following types have implementations for std::process::Termination:

• ! (the never type)
• () (the unit type)
• std::convert::Infallible
• std::process::ExitCode (with constants SUCCESS and FAIL)
• std::result::Result<T, E>

^[20]

Microsoft Windows uses 32-bit unsigned integers as exit codes,^[21][22] although the command interpreter treats them as signed.^[23]

Exit codes are directly referenced, for example, by the command line interpreter CMD.exe in the errorlevel terminology inherited from DOS. The .NET Framework processes and the Windows PowerShell refer to it as the ExitCode property of the Process object.