Are There Any Standard Exit Status Codes in Linux

Are there any standard exit status codes in Linux?

8 bits of the return code and 8 bits of the number of the killing signal are mixed into a single value on the return from wait(2) & co..

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <signal.h>

int main() {
    int status;

    pid_t child = fork();
    if (child <= 0)
        exit(42);
    waitpid(child, &status, 0);
    if (WIFEXITED(status))
        printf("first child exited with %u\n", WEXITSTATUS(status));
    /* prints: "first child exited with 42" */

    child = fork();
    if (child <= 0)
        kill(getpid(), SIGSEGV);
    waitpid(child, &status, 0);
    if (WIFSIGNALED(status))
        printf("second child died with %u\n", WTERMSIG(status));
    /* prints: "second child died with 11" */
}

How are you determining the exit status? Traditionally, the shell only stores an 8-bit return code, but sets the high bit if the process was abnormally terminated.

$ sh -c 'exit 42'; echo $?
42
$ sh -c 'kill -SEGV $$'; echo $?
Segmentation fault
139
$ expr 139 - 128
11

If you're seeing anything other than this, then the program probably has a SIGSEGV signal handler which then calls exit normally, so it isn't actually getting killed by the signal. (Programs can chose to handle any signals aside from SIGKILL and SIGSTOP.)

Listing all system exit status codes with descriptions

There can be no comprehensive list, because the meaning of command exit statuses is inherently command-specific. For a given command, you can usually get information about this on the respective command's manual page and Info documents.

In the case of

test$ hello
-bash: hello: command not found
test$ echo $?
127

the exit code 127 comes from bash, because the requested command itself couldn't be found.

In the case of

test$ expr 1 / 0
expr: division by zero
test$ echo $?
2

the exit code 2 comes from expr.

Some of these commands might be standardized or at least coordinated for several commands or a group of commands (e.g. "sh-compatible shells", I could imagine), but unless a command wants to conform to one of these conventions (and there are probably multiple conflicting conventions around), the command's authors are completely free to decide what they want their exit status codes to mean.

There's one important exception: All UNIX commands should adhere to this loose rule to be good citizens and provide meaningful composability (e.g. with pipes) on the command line:

• 0 means 'success' or "true"/"truthy"
• non-0 means (in a very broad sense) 'failure' or 'non-success' or "false"/"falsy"

As you can see, this still leaves a lot of room for interpretation, which is perfectly intended, because these meanings must be specific to the context of the individual commands. (Consider e.g. the false command, that has the very purpose to "fail", thus always returns a non-0 exit code.)

The list you found describes return codes for system calls. System calls are when a program makes a request (in)to the kernel and are not the same as command invocation, thus these return codes are not (necessarily) the same as command exit codes.

Program exit status conventions

This might help, http://tldp.org/LDP/abs/html/exitcodes.html those are the standard exit code. The rest of them I think are program dependant. basically you need to verify the documentation of the specific software you are looking for. As @devnull said, any exit code that is not zero implies an unsuccessful termination

What is a good Linux exit error code strategy?

The only convention is that you return 0 for success, and something other than zero for an error. Most well-known unix programs document the various return codes that they can return, and so should you. It doesn't make a lot of sense to try to make a common list for all possible error codes that any arbitrary program could return, or else you end up with tens of thousands of them like some other OS's, and even then, it doesn't always cover the specific type of error you want to return.

So just be consistent, and be sure to document whatever scheme you decide to use.

capturing exit codes properly and exit script at point of failure

Presumably the java command has a non-zero exit status, so you would do:

content=$(java -jar ${jarFilePath} -u ${username},${password} -n ${host} -c "${val_query}") 
rc=$?

if ((rc != 0)); then
   echo "Problem in executing query"
   exit 201
elif [[ -z $content ]]; then
   echo "Empty results"
fi

Note that the content variable holds the output of the command, not the exit status.

if ! $content; then ... will execute the value of the content variable as a command, and you'll get the "true" branch if that execution has a non-zero exit status (from the !).

All possible exit codes for cp

Here is how cp from coreutils-8.21 exits:

exit (ok ? EXIT_SUCCESS : EXIT_FAILURE);

There's nothing else than 0 or 1.

Different BASH exit status codes

You can return any integral exit code you like. The BASH scripting guide page you reference just says it could be confusing when debugging something that returns a well-known code for some other reason.

That page also mentions /usr/include/sysexits.h as an attempt to systematize exit codes for C programmers.

Best practices on setting exit status codes

Providing a descriptive error message to stderr is fine and well 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 the calling script could make an informed decision on how to handle the failure.

If the calling program does not wish to handle different failures differently it could always check the return code against > 0 - but don't assume this is the case.

---

Related Topics