In a bash script, what is the difference between `trap 'handler' TERM`, `trap '' TERM` and `trap - TERM`, and which of the three still applies to commands the script launches?

## The three forms `trap` takes an action followed by one or more conditions. The action decides everything: ```bash trap 'echo caught; exit 1' TERM # handler: run this command string trap '' TERM # ignore: discard the signal, run nothing trap - TERM # reset: restore the shell's default action ``` The distinction people miss is between the second and a *do-nothing handler*. `trap : TERM` looks equivalent to `trap '' TERM` — the handler `:` is the null command — but it is not. `trap : TERM` installs a handler; the signal is still delivered and the shell still wakes up to run a no-op. `trap '' TERM` sets the disposition to *ignored* at the OS level, and that difference is exactly what changes for child processes. ## What crosses into child processes A trap handler is a command string stored in this shell's trap table. A newly created process cannot inherit a bash command string — it may not even be a shell — so every command your script launches starts with the signals bash had at *default*, not with your handler. A background job the script starts will die on SIGTERM no matter what your script's TERM handler says. An ignored disposition is different, because ignoring is a property the kernel keeps for the process and it survives both fork and exec. Run this and the child outlives the signal: ```bash trap '' TERM sleep 30 & kill -TERM "$!" # discarded: the sleep keeps running ``` That asymmetry is worth internalising because it cuts both ways. It is useful when you deliberately want a subtree protected. It is a nasty surprise when you set `trap '' TERM` around a critical section, forget to clear it, and every process the script later starts quietly becomes unkillable by ordinary means — the operator reaches for `kill -9` and wonders why. ## Clearing and inspecting `trap - TERM` restores the default; `trap -` with no condition, or `trap - SIGNAL…` with a list, clears those specific ones. `trap -p` prints every trap currently set, in a form you can paste back: ```bash $ trap 'echo x' SIGTERM; trap -p TERM trap -- 'echo x' SIGTERM ``` `trap -p TERM` printing nothing means the signal is at its default. This is how you audit a long script or a sourced library that may have installed traps behind your back. ## Naming the signals Bash accepts three spellings for the same condition: the number (`15`), the bare name (`TERM`), and the `SIG`-prefixed name (`SIGTERM`). `trap -p` normalises its output to the prefixed form. Prefer the bare name in scripts you might run under a non-bash `/bin/sh`: POSIX specifies the un-prefixed names, and numbers are the worst choice of the three because the mapping is not identical on every platform. ## Signals you cannot set at all SIGKILL and SIGSTOP cannot be caught or ignored — that is enforced by the kernel, not the shell, so it holds for every program, not just bash. Bash does not protect you from writing it: `trap 'echo hi' KILL` is accepted silently, returns 0, and even shows up in `trap -p` output, but the handler can never run because the signal is never delivered to userspace. Treat any code that traps KILL as a bug wearing a disguise, and design for the fact that some terminations simply do not run your cleanup. ## Where the forms earn their keep The ignore form is for narrow, deliberate critical sections — a stretch of a script that must not be interrupted between two writes — bracketed by an immediate reset: ```bash trap '' INT write_both_halves trap - INT ``` The handler form is for cleanup and for forwarding signals to work the script is supervising. The reset form is for undoing either one, and for the re-raise idiom where a handler clears its own trap and then signals itself so the script dies with the honest 128+N status instead of a fabricated 0.