Stop getting burned by silent failures when your scripts use set -e

Technical Briefing | 11/10/2026

We all learned early on that adding set -e at the top of a script makes it crash if a command fails. It sounds perfect until you realize the shell is a pedantic mess. I once watched a deployment script silently march past a failed directory creation because it happened inside an if statement, leaving the next step to chown a path that didn’t exist. It took me an hour to figure out why the logs were empty and the server was half-configured.

Why your safety net is actually a hole

The issue is that set -e ignores errors in commands used as conditions for control structures. If you run a command inside a pipeline or a conditional, the exit status is masked by the wrapper. You stop seeing the error and start seeing the consequences. You might think you are covered, but the shell is just being polite about your broken logic.

if grep -q 'missing' /etc/config; then echo 'found'; fi || exit 1

• Avoid using complex logic inside if conditions if the failure of the command matters
• Use set -o pipefail to ensure the exit status of a pipe is not just the last command
• Explicitly check exit codes with if instead of relying on global shell flags for critical paths

Stop relying on global state

The right approach is to handle your failures right where they happen. Don’t leave your script’s fate to global flags that shift depending on how you write your loops. If a command is non-negotiable, check it manually with an if or || exit block. It makes your code longer, but at least you won’t be debugging a partial state at 3 AM.