Why set -e Doesn’t Always Exit Your Bash Script (And How It Can Break Production)

1. Introduction

Bash scripting is often seen as simple glue code — something you write quickly to automate tasks. But under that simplicity lies a set of behaviours that can quietly introduce bugs into production systems.
One of the most misunderstood features in Bash is set -e. Many developers believe they understand it. Fewer actually do.
Let’s explore a small script that exposes a subtle but critical behaviour — one that has caused real-world deployment failures.

2. Bash Puzzle

Consider the following script:

set -e

echo "start"

false && echo "this won't run"

echo "end"

set -e

echo "start"

false && echo "this won't run"

echo "end"

I know this code snippet looks simple, and most of you guessed the answer as well. Tell me in the comments how many of you guessed the answer below

start

If you think you’re right, you’re exactly where you need to be—because we’re about to explore set -e. In-depth, and by the end of this blog, you’ll walk away with insights that can help you avoid costly production mistakes when writing Bash scripts.

3. Understanding Set -e

Theset -e option (also known as errexit) tells Bash to exit immediately if a simple command exits with a non-zero status. However, it won’t stop if the failing command is part of certain structures, like inside an if condition, a while or until loop, part of && or ||, or if the result is reversed using !. Also, if an ERR trap is set, it will run before the script exits.

Now take a moment to read the code again—you’ll see why your earlier answer was incorrect.

Let’s go through the code snippet again and figure out what the actual output should be.

false && echo “this won’t run” this line alone is the tricky part of the code. Apart from this, all are just simple echo statements with set –e statement at the top.

• false runs → returns 1
• Because it’s part of an && expression → Bash allows it (as above statement for set -e we learn those exceptions)
• echo "this won't run" is skipped
• Script continues execution

So the actual output of our code is

start
end

start
end

I hope you now understand how set -e works inside our Bash script.

4. Why This Is Dangerous and how to avoid this?

Now that we understand how set -e works, writing scripts like this for production can end up being very costly. In reality, it can introduce silent failures into your scripts.

Let’s consider a new real-world example where we have to build and deploy our project.

#!/bin/bash
set -e 
build_project && deploy_project
echo "Deployment completed"

#!/bin/bash
set -e 
build_project && deploy_project
echo "Deployment completed"

Now imagine this: if the build_project command fails, the deploy_project Step will be skipped—but the script will still print “Deployment completed.” That’s misleading and can cause serious issues in production.

To write reliable Bash scripts, you need to be explicit. Let’s look at some safer patterns that can help avoid these kinds of issues in production.

4.1 Avoid chaining critical commands

Instead of:

build && deploy

build && deploy

Use:

build
deploy

build
deploy

This ensures:

• If build fails → script exits immediately

4.2 Use explicit error handling

if ! build_project; then
  echo "Build failed"
  exit 1
fi

deploy_project

if ! build_project; then
  echo "Build failed"
  exit 1
fi

deploy_project

5. Conclusion

set -e is one of those Bash features that looks simple on the surface but exposes how deep your understanding really is. It does not blindly exit on every failure—it only exits when a command fails outside controlled contexts like &&, ||, conditionals, or loops. That means failures can be silently ignored, especially in real-world scripts, leading to behaviour that looks correct but isn’t.

This exact nuance is what separates someone who “knows Bash” from someone who actually understands how Linux systems behave under the hood. And this is the kind of concept that frequently shows up in Linux and DevOps interviews—not directly as a question, but as a trap in debugging, scripting, or system design discussions. If you can confidently explain why this script doesn’t exist, you’re already ahead of most candidates. If you want more of these interview-level insights, tricky edge cases, and real-world scenarios, I’ve put together a Linux Interview Bundle on Gumroad that’s designed to help you think like a senior engineer—not just memorise commands.