From 6598c9a8d195193cf168cbee515bd383d69c1a1b Mon Sep 17 00:00:00 2001 From: Einhard Leichtfuß Date: Mon, 23 Dec 2024 12:28:30 +0100 Subject: Add errexit, inherit_errexit Also amended related notes in `docs/`. See comments and `docs/error-handling.md` on why. --- docs/error-handling.md | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/error-handling.md b/docs/error-handling.md index 483123f..27d8054 100644 --- a/docs/error-handling.md +++ b/docs/error-handling.md @@ -11,6 +11,11 @@ ## Limitations +### Introductory notes + +* Much of the below is from empirical evidence (aka testing). + + ### Backgrounded process * An error in a backgrounded process (e.g., `false &`) is ignored by the @@ -59,14 +64,35 @@ stack trace to be printed in the current [(sub-)](subshell.md)shell, but only a simple message mentioning the file and line number. * If there is no subshell involved, no stack trace is printed at all. - * Note that unset variable errors are also caught in - `declare var=$undef_var` (compare [Subshell section](#Subshell)). + * Note that unset variable errors are generally also caught in + `declare var=$undef_var` and `true $undef_var`. + * Compare [Subshell section](#Subshell). + * This does not hold if the shell is interactive (`bash -i`). * This is arguably not a big problem; such errors should mostly be quickly spotted by simple testing (or some static analysis tool). * Exceptions: Usage of `declare -n` and `eval` with dynamic variable names. +### Array variables + +* Attempting to assign `var[0]=(foo bar)` or `var['x']=(foo bar)` (where + `$var` is an array variable or associative array variable, respectively) + causes an error to be printed instead of a stack trace in the innermost + (sub-)shell. + * Compare behaviour of [unset variables](#Unset_variables). + * See also `src/basic.bash#errexit`. +* Attempting to assign `var['x']=foo` where `$var` is not an associative array + variable, has weird behaviour: + * In any case, the [(sub-)](subshell.md)shell where the error originally + occurs does not print a stacktrace, but a simple error message. + * If at least one subshell is involved, all but the lowest subshell print + a stack trace and all (sub-)shells exit correctly. + * If no subshell is involved, the error message is printed, but execution + is not aborted. + * Note that unlike for the preceding case, `set -o errexit` is irrelevant. + + ### Pipes * A pipeline is considered an error iff the last command returns non-zero. -- cgit v1.2.3