Signal Handling with trap

Build the mental model

trap 'command' SIGNAL registers a piece of code — a single command or, more usefully, a function name — to run whenever bash receives that signal, and it stays registered until you replace it or the shell exits. The most useful signal by far is EXIT, a pseudo-signal (not a real POSIX signal) that bash itself fires whenever the script finishes for any reason at all: normal completion falling off the last line, an early exit call, or a set -e abort partway through. Inside an EXIT handler, $? still holds the exit status that triggered it, which is useful if you want cleanup to behave slightly differently after a failure versus a clean run. trap 'rm -f "$tmpfile"' EXIT guarantees a temp file gets deleted no matter which of those paths the script takes, which is far more reliable than putting a single rm at the bottom of the script and hoping every code path — including every early exit and every error — actually reaches it. You can also trap real signals like SIGINT (sent when someone presses Ctrl+C) and SIGTERM (sent by kill by default) to let a script shut down gracefully instead of dying wherever it happened to be — finishing a write, releasing a lock, printing a partial-progress message — before exiting. One thing worth knowing up front: trap does not stack handlers. Calling trap a second time for the same signal doesn't add a second handler alongside the first; it silently replaces it, so if a script needs several cleanup actions on EXIT, they all belong inside one function registered once, not several separate trap calls.

Connect it to a real scenario

Imagine a backup script that downloads a large file to a temp path, verifies its checksum, then compresses it and uploads the result — several steps, each of which could be interrupted. If the user hits Ctrl+C halfway through the download, or the network drops and the script errors out under set -e, an untrapped script just stops wherever it was, leaving a half-downloaded temp file sitting on disk with no cleanup step ever reached. Adding trap cleanup EXIT right after the temp file is created — where cleanup is a function that does rm -f "$tmpfile" — changes that: this handler now runs automatically once, whichever of the script's possible endings actually happens, normal completion, a set -e triggered error, or an interrupt caught by a separate SIGINT/SIGTERM trap that calls exit. Because the EXIT trap fires last regardless of the path taken, you only have to write the cleanup logic once, in one place, instead of duplicating a rm call before every exit point and every error branch in the script — which is exactly the kind of thing that's easy to add today and easy to forget three edits from now.

• trap 'command' EXIT runs code no matter how a script ends — normal exit, error, or interrupt
• trap ... SIGINT SIGTERM lets a script shut down gracefully on Ctrl+C or kill instead of dying abruptly
• The rm -f "$tmpfile" EXIT trap pattern is the standard way to guarantee temp-file cleanup

Try the working example

#!/bin/bash
set -euo pipefail

tmpfile=$(mktemp)
echo "created temp file: exists=$([ -f "$tmpfile" ] && echo yes)"

cleanup() {
  rm -f "$tmpfile"
  echo "cleanup ran: tmpfile removed"
}
trap cleanup EXIT

on_interrupt() {
  echo "caught SIGINT, shutting down gracefully"
  exit 1
}
trap on_interrupt SIGINT SIGTERM

echo "doing some work..."
echo "some data" > "$tmpfile"
echo "wrote to tmpfile, contents: $(cat "$tmpfile")"

echo "script ending normally, EXIT trap will fire next"

Running the script above prints:

created temp file: exists=yes
doing some work...
wrote to tmpfile, contents: some data
script ending normally, EXIT trap will fire next
cleanup ran: tmpfile removed

GNU Bash Manual — Signals — Bash / Shell Scripting