A bash script starts with `set -e`, yet a command that fails inside it does not stop the script. In which contexts does bash deliberately ignore `set -e`, and how do you make the failure surface anyway?

## The rule behind the exceptions The exceptions look arbitrary until you see the principle: **bash suspends `errexit` wherever a non-zero exit status is being used as a value rather than treated as an error.** If you wrote `if grep -q PATTERN file; then`, a non-zero status from `grep` means "not found", which is the answer you asked for — killing the script there would make `if` useless. The documented contexts where `set -e` does not act are: - any command in the condition list of `if`, `elif`, `while` or `until`; - any command in a `&&` or `||` list **except the last one**; - any command whose status is inverted with `!`; - any command in a pipeline other than the final one (this one is really about how a pipeline's status is computed, and `set -o pipefail` is the knob that changes it). ## The exception that actually bites: functions Suspension is not per-command; it applies to everything executed in that position, including the whole body of a shell function invoked there. ```bash #!/usr/bin/env bash set -e check() { false # errexit is suspended here... echo "still running" } if check; then # ...because check runs as an if condition echo "check succeeded" fi ``` This prints `still running` and then `check succeeded`. Both surprises are present at once: the `false` did not stop the function, and the function's return status is the status of its last command — the successful `echo` — so the `if` takes the true branch. A validation function written this way reports success no matter what it finds. The same thing happens with `check && deploy`, or `if ! check; then`. This is why "wrap it in an `if` to be safe" is bad advice: putting a call in a tested position *removes* protection from everything it runs. ## The assignment blind spot A plain assignment does propagate the status of its command substitution, so under `set -e` this aborts as you would hope: ```bash out=$(exit 3) # the assignment's status is 3 — errexit fires ``` But when the assignment goes through a declaration builtin — `local`, `declare`, `export`, `readonly` — the status reported is the *builtin's* status, which is 0 unless the builtin itself was misused: ```bash fetch() { local out=$(exit 3) # status is local's, which is 0 echo "survived: ${out:-empty}" } ``` The fix is to split declaration from assignment: ```bash fetch() { local out out=$(exit 3) # now the assignment's own status is seen echo "unreachable under set -e" } ``` Static analysis flags this pattern, and it is worth internalising because it appears in almost every real script that captures command output into a scoped variable. ## Other places nothing fires - **Backgrounded commands.** `cmd &` returns immediately with the status of the fork, not of `cmd`; the eventual failure surfaces only when you collect it. - **Arithmetic commands that evaluate to zero.** `((count++))` returns status 1 when the value it produced is 0, which under `set -e` terminates the script on a perfectly ordinary counter increment. Writing `count=$((count + 1))`, or `((count++)) || true`, avoids it. - **Commands that fail without a non-zero status.** Errexit only sees exit codes. A tool that prints an error to stderr and exits 0 is invisible to it. ## What to do instead Treat `set -e` as a backstop for the failures you did not anticipate, and handle the ones you did anticipate explicitly: 1. **Check what matters.** `cmd || die "cmd failed"` works in every context, including the ones where errexit is suspended, and it produces a message. 2. **Restructure rather than test.** If a function must abort on failure, do not call it from an `if`. Let it run in a plain statement position and have it call `die` itself. 3. **Capture the status when you need the value.** `if ! out=$(cmd); then die "..."; fi` keeps both the output and the check. 4. **Split declaration from assignment** in every function that captures output. 5. **Add an ERR trap** so that when errexit does fire, the script says where and why instead of dying silently. The interview point is not memorising the list. It is showing that you know `set -e` encodes a policy with holes in it, and that anything the script genuinely depends on gets checked by hand.