safe automation

Overview

Automation is powerful, but a careless script can do a lot of damage very fast. Safe automation means writing scripts that fail predictably, handle errors, and avoid destructive mistakes. This lesson covers practices that make automation trustworthy.

Learning objectives

• Apply defensive scripting practices.
• Explain error handling and safe defaults in Bash.
• Avoid common destructive scripting mistakes.

Core concept

Several practices make Bash scripts safer:

• Fail fast — set -e exits on the first error; set -u errors on undefined variables; set -o pipefail catches failures inside pipelines. Combined: set -euo pipefail.
• Quote everything — always "$var" to prevent word-splitting and globbing surprises.
• Validate inputs — check arguments and paths before acting on them.
• Be careful with destructive commands — especially rm -rf, and never with unvalidated variables (e.g. rm -rf "$dir/" where $dir could be empty).
• Dry-run and test — try scripts on safe data first.

How it works

set -euo pipefail turns silent failures into immediate, visible stops, so a script does not blunder onward after something goes wrong. Quoting protects against filenames with spaces or special characters that would otherwise break commands or match unintended files. Input validation ensures the script only acts when it has sensible values — critical before destructive operations, since an empty or wrong variable in a rm -rf can delete far more than intended. Testing on non-critical data catches logic errors before they cause harm.

Practical example

#!/bin/bash
set -euo pipefail

target="${1:?usage: cleanup.sh <directory>}"   # require an argument, else exit
if [[ ! -d "$target" ]]; then
  echo "Not a directory: $target" >&2
  exit 1
fi
# safe now: target is validated and quoted
find "$target" -name '*.tmp' -type f -delete

set -euo pipefail makes failures stop the script, the ${1:?...} requires an argument, and the directory check validates input before any deletion — so a missing or wrong argument aborts safely instead of causing damage.

Cybersecurity relevance

Safe automation is both an operational and a security concern. Scripts often run with elevated privileges or on many systems, so a defect can cause widespread damage (a classic disaster is a variable expanding to empty in rm -rf "$var"/, deleting the filesystem root). Defensive practices also reduce injection risks by validating and quoting inputs. Automation that handles untrusted data must be especially careful, since a flaw becomes a repeatable, scalable vulnerability. Reliable, predictable scripts are essential wherever automation touches real systems.

Common mistakes

• Not using set -euo pipefail, letting errors pass silently and compound.
• Unquoted variables in destructive commands (e.g. rm -rf $dir/), risking catastrophic deletion.
• Skipping input validation and testing, so bugs run against real data with full effect.

Key takeaways

• Make scripts fail fast with set -euo pipefail, and always quote variables ("$var").
• Validate inputs and be extremely careful with destructive commands, especially rm -rf with variables that could be empty or wrong.
• Test on safe data first; because automation runs with privilege and at scale, defects and unvalidated inputs become serious, repeatable security and reliability risks.

Check your understanding

• What do set -e, set -u, and set -o pipefail each protect against?
• Why is an unquoted or unvalidated variable in a rm -rf command especially dangerous?