Bash – Is the exit status of a command implemented by the command or a shell process which executes the command

bashcommandexit-status

From bash manual

The exit status of an executed command is the value returned by the
waitpid system call or equivalent function. Exit statuses fall between
0 and 255, though, as explained below, the shell may use values above
125 specially. Exit statuses from shell builtins and compound commands
are also limited to this range. Under certain circumstances, the shell
will use special values to indicate specific failure modes.

What determines the exit status of an executed command,
- the command itself,
  i.e. does the implementation of the command determines the exit status, i.e. is determination of the exit status of an executed command an inherent property of the command, just like parsing the command line arguments to an execution of a command is inherent to the command, or
- the shell process which executed the command?
  The waitpid system call mentioned above seems to me that the exit
  status of an executed command is implemented by the shell process, and the command itself has nothing to do with the exit status of an execution of itself.
In a bash process, when can we get the exit status of an executed
command,
- only when the bash process is interactive, or
- regardless of whether the bash process is interactive or non-interactive? When a bash process is non-interactive, how can we
  retrieve the exit status of a command executed in the bash process?

Best Answer

The command itself can provide the exit status, via the argument to an exit() system call. The shell (or other program, how about system() in Perl or PHP?) can pick up a child process' exit status via wait() or waitpid() system calls. The Unix/Linux/*BSD kernels all arrange to deliver SIGCHLD to the parent process when a child process changes status.

But there are other circumstances. A process terminated via SIGKILL doesn't have a chance to exit. A process that dereferences an invalid address won't have a chance to call exit() unless it has a SIGSEGV signal handler installed. In those cases, the kernel calculates an exit status that includes a bit that means "killed by a signal", and what signal caused the process to get killed. That kernel-calculated exit status is delivered to the killed process' parent process.

Related Solutions

Bash – Using Reserved Codes for Exit Status of Shell Scripts

There have been several attempts to standardize the meanings of process exit codes. In addition to the one you mention, I know of:

the BSDs have sysexits.h which defines meanings for values from 64 on up.
GNU grep documents that exit code 0 means at least one match was found, 1 means no matches were found, and 2 means an I/O error occurred; this convention is obviously also useful for other programs for which the distinction between "nothing went wrong but I didn't find anything" and "an I/O error occurred" is meaningful.
Many implementations of the C library function system use exit code 127 to indicate the program doesn't exist or failed to start.
On Windows, NTSTATUS codes (which are inconveniently scattered all over the 32-bit number space) may be used as exit codes, particularly the ones that indicate a process was terminated due to catastrophic misbehavior (e.g. STATUS_STACK_OVERFLOW).

You can't count on any given program obeying any particular one of these conventions. The only reliable rule is that exit code 0 is success and anything else is some sort of failure. (Note that C89's EXIT_SUCCESS is not guaranteed to have the value zero; however, exit(0) is required to behave identically to exit(EXIT_SUCCESS) even if the values are not the same.)

Bash – Which of the following shell operations are performed inside the function body when running a function definition and when calling a function

<rant>
“running a function definition” and “running the definition of a function” are not common idioms. I expect that most people would refer to that simply as “defining a function”. OK, that phrase might be interpreted to refer to

conceptually specifying the characteristics and interfaces (parameters and other inputs, processing, and outputs) of a function (this is an activity performed by a person, or a group of people)

choosing the implementation of a function; i.e., what commands to use in the function body. This is an activity performed by a person, or a group of people, possibly using paper, whiteboards, and/or blackboards.

typing the implementation of a function into a text editor or directly into an interactive shell (this, of course, is also an activity performed by a person, or possibly a group of people, or possibly a very intelligent and dexterous cat, dog or monkey)

If you fear confusion with the above, you might be better served by phrases like “reading a function definition” and “processing the definition of a function”.

You say, “A function definition is a command.” It’s not clear what a claim like that even means — it’s a matter of semantics — but, at the semantic level, it’s debatable. Section 3.2 of the Bash manual (Shell Commands) lists six kinds of shell commands: Simple Commands, Pipelines, Lists, Compound Commands, Coprocesses, and GNU Parallel. Function definitions don’t fit well into any of those categories.
</rant>

Getting to your question, and looking at the seven steps / operations,

Reading input obviously has to happen before anything else can happen. It’s, again, a matter of semantics — you could say that reading input from a file or other stream text source is part of “reading a function definition” or that it is a prerequisite / prelude to “processing the definition of a function”.
Breaking the input into words and operators is clearly part of “processing the definition of a function”.
- Breaking the input into tokens is, of course, a prerequisite / prelude to parsing the tokens (step 3, below).
- The manual says, “Alias expansion is performed by this step,” and you show in the question that you know that alias expansion happens when the function definition is read.
Parsing the tokens. This must at least start during the “processing the definition of a function” phase for the shell to realize that it is looking at a function definition and not a simple command. Beyond that, we can do this simple experiment: type either of the following into a shell:
```
myfunc1() {                     myfunc2() {
    <               or              ;
}                               }
```
It will fail with a “syntax error” before you get a chance to type the }. (> and & produce the same effect.) So clearly this step is part of processing the definition of the function.

Performing the various shell expansions is part of calling the function.
- You show in the question that you know that parameter expansion does not happen when the function definition is read.
- It’s equally trivial to demonstrate that pathname / filename expansion does not happen when the function definition is read. In your example, change echo $var (which should be echo "$var", but that’s another matter) to echo *.
  - If you look at the function definition, you’ll see that it still says echo * and has not been expanded.
  - Change directory (cd) and/or create file(s) and/or delete file(s) and/or rename file(s), and then call (execute) the function. You’ll see that it outputs the current list of files¹ in the current directory, and doesn’t reflect the contents of the directory where/when you defined the function.
Performing redirections is part of calling the function. This is also trivial to verify. In your example, change echo $var to echo hello > myfile.
- If you look at the function definition, you’ll see that it still says > myfile.
- Check the directory, and you’ll see that myfile has not been created (yet).
Executing the command — do you really need to ask?
Waiting for the command to complete can’t possibly happen until the command has been executed (step 6), so this obviously is performed only when calling the function.

In other words, exactly what @ilkkachu said.

The one exceptional special case I can think of is that steps 2 and 3 (lexical analysis and parsing) occur (again) when executing a function if the function contains eval statements — but I believe that that’s outside the scope of what your question is really asking.
____________
¹ excluding hidden (dot-) files, unless you have said shopt -s dotglob

Best Answer

Related Solutions

Bash – Using Reserved Codes for Exit Status of Shell Scripts

Bash – Which of the following shell operations are performed inside the function body when running a function definition and when calling a function

Related Question