Introduction

To stop a Bash script completely when a condition occurs, use exit. That ends the current script process and returns a status code to whatever invoked it, such as your shell, a CI runner, cron, or another script.

The detail that matters is not just "use exit." Real scripts also need clear exit codes, function-level error handling, and cleanup so an early failure does not leave behind broken state.

Use exit at Top Level

For a straightforward guard, put the condition in an if block and terminate immediately when it fails:

1#!/usr/bin/env bash
2
3if [[ ! -f config.env ]]; then
4  echo "config.env is missing" >&2
5  exit 1
6fi
7
8echo "Continuing with the script"

This is the clearest possible answer. exit 1 means the script failed. If the condition is fatal, stop at the point where you detect it instead of letting the script continue into a half-valid state.

Choose Exit Codes Deliberately

By convention, 0 means success and nonzero means failure. Different nonzero codes can communicate different failure types:

1#!/usr/bin/env bash
2
3if [[ $# -lt 1 ]]; then
4  echo "Usage: $0 <input-file>" >&2
5  exit 2
6fi
7
8if [[ ! -r "$1" ]]; then
9  echo "Input file is not readable: $1" >&2
10  exit 3
11fi

You do not need dozens of custom codes, but using more than one failure value can make automation and log inspection much easier.

return Inside Functions, exit for the Script

Inside a function, prefer return so the caller decides whether the whole script should stop:

1#!/usr/bin/env bash
2
3check_input() {
4  if [[ -z "$1" ]]; then
5    echo "Missing input" >&2
6    return 1
7  fi
8}
9
10check_input "$1" || exit 1
11echo "Main script continues"

This keeps helper functions reusable and makes control flow easier to follow. A function reports failure; the top-level script decides whether that failure is fatal.

Using exit deep inside helpers can work, but it often makes larger scripts harder to reason about because any nested call can abruptly terminate everything.

Clean Up Before You Exit

If the script creates temporary files or acquires resources, use trap so cleanup happens even on failure:

1#!/usr/bin/env bash
2
3tmp_file=$(mktemp)
4trap 'rm -f "$tmp_file"' EXIT
5
6if [[ ! -r input.txt ]]; then
7  echo "input.txt is missing" >&2
8  exit 1
9fi
10
11echo "work in progress" > "$tmp_file"

The EXIT trap runs whether the script finishes normally or exits early. This is one of the simplest ways to avoid stale temp files and half-finished local state.

Use set -e Carefully

If your rule is "stop when any command fails," Bash can help:

1#!/usr/bin/env bash
2set -euo pipefail
3
4cp source.txt backup.txt
5./generate-report.sh
6echo "done"

This is useful, but it is not the same as explicit failure logic. set -e has exceptions around conditionals, command substitutions, and some compound commands. It is best treated as a safety net, not as a complete error-handling strategy.

For important branches, write the condition plainly:

1if ! ./deploy.sh; then
2  echo "Deployment failed" >&2
3  exit 1
4fi

That is less surprising than depending entirely on shell option semantics.

Remember That Subshells Behave Differently

An exit inside a subshell does not necessarily stop the parent script:

1#!/usr/bin/env bash
2
3( echo "inside subshell"; exit 1 )
4echo "parent script is still running"

This matters when your condition is inside parentheses, a pipeline, or command substitution. If you need the main script to stop, make sure the failure reaches the main shell context and is checked there.

Common Pitfalls

The most common mistake is using return at top level in a normal script. return is for functions and sourced files, not for direct script termination.

Another frequent issue is assuming set -e always behaves exactly as expected. It helps, but it does not remove the need for explicit checks where failure is part of normal branching.

Cleanup is also easy to forget. If the script can fail after creating files, directories, or background jobs, add trap before the risky work begins.

Finally, avoid hiding important termination logic in dense one-liners when the condition is complex. A regular if block is often easier to read and safer to maintain.

Summary

• Use exit to terminate the entire Bash script when a fatal condition occurs.
• Return nonzero exit codes so callers can detect and classify failures.
• Prefer return inside functions and let top-level code decide when to call exit.
• Use trap to clean up temporary resources before the script stops.
• Treat set -euo pipefail as helpful protection, not as a replacement for clear error handling.