Temp Files, Locking and Idempotency

## The last line is one exit path out of many A script has far more ways to stop than to finish. The cleanup on the final line runs only if control actually reaches it, and these all prevent that: - an error branch: `[[ -f $input ]] || { echo "missing" >&2; exit 1; }` - a strict-mode abort: under `set -e`, any unchecked failing command ends the shell where it stands - `set -u` firing on an unset variable, or a failing pipeline under `pipefail` - an interrupt: the operator presses Ctrl-C, or CI cancels the job and sends `SIGTERM` - `exec some-other-program`, which replaces the shell image so no later shell line ever runs - a `return` from a function that the caller then turns into an exit On a build agent this is not cosmetic. Each skipped cleanup leaves a directory under `/tmp` (or wherever `TMPDIR` points), and after a few hundred failed runs the filesystem fills and *every* job starts failing for an unrelated-looking reason. ## Bind the cleanup to the shell, not to a line The idiom is to register the removal once, immediately after creating the directory: ```bash workdir=$(mktemp -d) || exit 1 cleanup() { rm -rf -- "${workdir:?}"; } trap cleanup EXIT INT TERM ``` `EXIT` fires whenever the shell terminates: falling off the end, an explicit `exit N` from anywhere including inside a function, and an abort caused by `set -e`. The exit status the script reports is preserved — the handler does not silently turn a failure into a success unless it calls `exit` itself. In bash the `EXIT` handler also runs when the shell is terminated by a catchable signal such as `SIGINT`, `SIGTERM` or `SIGHUP`. Not every shell behaves that way — `dash` and other POSIX shells vary — so scripts that may run under `/bin/sh` list `INT TERM HUP` alongside `EXIT`. Nothing at all can run on `SIGKILL`, on a hard reset, or when the container's OOM killer removes the process, which is why a fleet still wants a periodic reaper for its scratch directory in addition to well-behaved scripts. ## Getting the registration right **Register immediately after creation.** Any code between `mktemp -d` and the `trap` line is a window in which the script can die and leak. Conversely, registering *before* the directory exists means the handler may run with the variable empty. **Guard the variable.** `rm -rf -- "$workdir"` with `workdir` empty expands to `rm -rf --` (harmless), but the common variants are not: `rm -rf "$workdir"/*` with an empty variable becomes `rm -rf /*`. Writing `"${workdir:?}"` makes the expansion abort loudly instead of proceeding on an empty value, and the `--` stops a path that begins with a dash from being read as options. **Quoting inside the trap matters.** `trap "rm -rf $workdir" EXIT` expands the variable *when the trap is registered*; `trap 'rm -rf "$workdir"' EXIT` defers expansion to when the handler runs. Calling a named function, as above, sidesteps the confusion entirely and lets the cleanup grow beyond one command. **There is only one EXIT handler.** A later `trap something EXIT` replaces the earlier one rather than adding to it, so a script (or a sourced library) that registers its own cleanup can silently discard yours. If several things need tearing down, put them all in one `cleanup` function. **The handler must not fail noisily.** It runs on the error path too, when the thing it wants to remove may already be gone or half-created. Use `rm -rf` (which tolerates a missing target) and avoid commands that could abort mid-cleanup, so the first tidy-up step is not prevented by the second one erroring. ## Prefer one directory to many files Tracking six individual temp files means six chances to forget one. `mktemp -d` gives a single object: everything scratch goes inside it, and one `rm -rf` of the directory is the whole cleanup. It also makes the failure mode debuggable — set an environment flag such as `KEEP_WORKDIR=1` that the cleanup function honours, so a developer investigating a failure can rerun the script and keep the evidence, while the default stays "leave nothing behind".