A CI deploy script dispatches on its first argument with `case "$1" in start) do_start ;; stop) do_stop ;; esac` and then exits. Someone runs `./deploy statr`: nothing is printed, the exit status is 0, and the pipeline reports success. Why does bash behave that way, and how would you harden the dispatcher?

## What a case statement returns Two rules, and the second one is the whole bug: 1. If a pattern matches, the `case` returns the exit status of the **last command executed** in that clause's command list. 2. If **no** pattern matches, no commands run and the `case` returns **0**. Rule 2 is defensible — the compound command itself did not fail, it simply had nothing to do — but it means `case` is a silent no-op for unexpected input, and silence is the worst possible behaviour for a dispatcher. ## Why the pipeline went green Trace `./deploy statr`. The word `statr` is compared with `start`, then with `stop`. Neither matches. There is no other clause. Bash falls out of the `case`, the script reaches its end, and the script's exit status is the status of the last command it ran — the `case` — which is 0. The CI step sees 0 and reports success. Nothing was deployed, nothing was logged, and the failure only surfaces later when someone wonders why the new build is not live. It is worth being explicit about the thing that does *not* help: enabling strict error handling changes nothing here, because there is no non-zero status anywhere in the story. This is a class of bug that error-handling flags structurally cannot catch — the script did precisely what you wrote, and what you wrote was "if the input is unrecognised, succeed". ## The catch-all clause The `*)` pattern matches any word, so as the final clause it is the default branch. A hardened dispatcher: ```bash case "${1:-}" in start) do_start ;; stop) do_stop ;; '') printf 'missing subcommand\n' >&2; usage; exit 2 ;; *) printf 'unknown subcommand: %s\n' "$1" >&2; usage; exit 2 ;; esac ``` Four things are deliberate here. **The error text goes to stderr.** A usage error is diagnostic output; sending it to stdout pollutes anything that captures the script's output and hides the message when stdout is redirected to a log. **The exit status is non-zero.** Any non-zero value works; `2` is a common convention for "you called me wrong" as distinct from `1` for "the work failed". Pick one convention and use it across your scripts, because the caller can only act on the number. **Empty gets its own clause.** `./deploy` with no arguments is a different user mistake from `./deploy statr`, and a different message costs one line. The `''` pattern matches the empty word. **The word is written `"${1:-}"`.** With `set -u` in force, referring to `$1` when the script was called with no arguments aborts before the `case` is even evaluated, so the empty-argument branch would never be reached; supplying an empty default keeps the dispatcher in control of its own error reporting. ## The other half: propagating the branch's status Adding the catch-all fixes unknown input, but the matched path deserves the same scrutiny. Because a `case` returns the status of the last command in the matched clause, `start) do_start ;;` already propagates `do_start`'s failure — provided `do_start` is the last thing in the clause. Append a helpful `echo "done"` after it and you have overwritten the status with the `echo`'s 0, resurrecting the same false-green in a new place. Keep the call last, or capture and re-raise its status explicitly. ## The review rule Treat a `case` used as a dispatcher or a validator as incomplete until it has a `*)` clause. It is one of the cheapest review rules in shell: scan to `esac`, and if the last pattern is not `*`, ask what happens for input nobody thought of. The answer is always the same — nothing happens, successfully.