Safe Automation & Idempotency

What is it?

Safe automation adds guardrails: `set -euo pipefail` to fail fast, checks before destructive actions, and idempotency (running it twice does no extra harm). It is scripting for production, not the demo.

Why it matters

A script runs on many hosts; a small unsafe assumption (an unset variable, no error check) becomes a fleet-wide outage. Safety is what makes automation trustworthy.

Where you see it

`set -euo pipefail` at the top; `rm -rf "${dir:?}"/...` to refuse an empty variable; a check that a target exists before acting on it.

What normal looks like

Scripts that stop on the first error, validate inputs, are safe to re-run, and log what they did — production-grade automation.

What suspicious looks like

The infamous `rm -rf $DIR/` where $DIR is empty (deletes /), no error handling so it charges past failures, or a non-idempotent script that duplicates work on re-run.

How analysts investigate

Before trusting a script, ask: does it stop on error, what happens if a variable is empty, and is it safe to run twice — if any answer is bad, it is not production-ready.

Common beginner mistakes

rm -rf on a path built from an unvalidated variable that could be empty.
No `set -e`, so the script keeps going after a critical step failed.

Guardrails before power

  #!/usr/bin/env bash
  set -euo pipefail            # stop on error, unset var, pipe failure
  dir="${1:?usage: cleanup <dir>}"   # refuse empty argument
  [ -d "$dir" ] || { echo "no such dir"; exit 1; }
  find "$dir" -type f -mtime +30 -delete   # safe, bounded, re-runnable
  NEVER: rm -rf $dir/   (empty $dir = rm -rf /)

set -euo pipefail, validated inputs and idempotency turn a risky script into safe production automation.

Quick check

Why is `rm -rf "$DIR"/` dangerous without validating $DIR?

A quick self-check — it doesn't affect your XP or progress.