Writing shell scripts that fail safely

Goal

Make small automation scripts stop at the first unexpected condition instead of continuing with wrong data, and make word-splitting and globbing bugs impossible.

Prerequisites

Bash (the rules differ for POSIX sh) and ShellCheck installed locally or in the pipeline.

Steps

1. Start with #!/usr/bin/env bash and set -euo pipefail: exit on error, on unset variables, and when any command in a pipeline fails.
2. Quote every expansion: "$var", "${array[@]}", "$(command)". Unquoted expansions split on whitespace and expand globs.
3. Use arrays for lists of arguments; never build command lines in a string and eval them.
4. Test with [[ ... ]], compare numbers with -eq, and use $(...) instead of backticks.
5. Handle the expected failures explicitly (if ! cmd; then ...) so that set -e covers only the unexpected ones; use trap cleanup EXIT for temporary files.
6. Run ShellCheck on every script in CI and fix or explicitly annotate each finding.
7. Rewrite in a real language once a script needs data structures, error types or more than a screen of logic.

Expected result

Scripts abort with a clear line number on failure; file names with spaces and special characters work; reviewers can rely on ShellCheck for the mechanical parts.

Limits and test basis

set -e has documented exceptions (commands in conditions, functions in pipelines) that surprise; ShellCheck's wiki explains them. pipefail can mask which stage failed; log exit statuses when needed. Guidance follows the cited references.

Tooling

Run ShellCheck on every script in CI and locally; it detects unquoted expansions, unsafe [ ] comparisons, useless cat and dozens of portability issues, and its warning codes link to explanations. Combine it with bash -n for syntax and, for scripts that must be portable, checkbashisms.