In bash you write `case $answer in y|Y) confirm ;; esac`, leaving the word unquoted. Which expansions does bash apply to that word before matching, and what changes if you quote a pattern instead, as in `"*")`?

## What bash does to the word When bash reaches `case WORD in`, it expands WORD using tilde expansion, parameter and variable expansion, command substitution and arithmetic expansion, and then performs quote removal. What it pointedly does **not** do is word splitting or pathname expansion. The result is always exactly one word, no matter what it contains. This is a real semantic difference and not a style opinion. In most command positions, an unquoted `$file` holding `my report.txt` becomes two arguments, which is how `[ $file = x ]` ends up with too many arguments and how `for f in $files` silently splits on spaces. In a `case` word that cannot happen: ```bash file='my report.txt' case $file in *.txt) echo "one word, spaces and all: $file" ;; esac ``` The same protection covers globbing: if the variable held `*`, an unquoted use elsewhere might expand to the filenames in the current directory, but as a `case` word it stays the single character `*` and is matched against the patterns as such. ## Should you quote it anyway? Yes, most style guides say `case "$1" in`, and it is a reasonable habit — quoting is free here, it removes the need for the reader to know this special rule, and it survives the code being copied into a context where splitting *does* apply. But when someone tells you the unquoted form is a latent bug, they are wrong about `case` specifically, and knowing exactly which construct protects you is what separates cargo-culted quoting from understood quoting. ## What bash does to each pattern Patterns are expanded too, before they are used for matching. That means a pattern can be built from a variable: ```bash prefix=v case $tag in "$prefix"*) echo "a versioned tag" ;; esac ``` Here the quoted `"$prefix"` contributes literal text and the unquoted `*` after it is a live wildcard. That mix is the whole point of the quoting rule for patterns: **any quoted portion of a pattern is matched as a literal string**, while unquoted metacharacters keep their pattern meaning. Two consequences follow, and both show up in real bugs. First, quoting the default clause breaks it. `"*")` is not a catch-all — it matches one word, the single asterisk character. A block that ends with `"*") echo unknown ;;` will fall through to nothing for every ordinary input, and bash reports no error. Second, an *unquoted* variable in a pattern position brings its own metacharacters to life. If `$prefix` holds `a*`, then `case $tag in $prefix)` matches anything starting with `a`, not the two-character string `a*`. When the variable comes from outside the script, that is a small trust decision: the caller now influences which branch runs. Quote the variable in the pattern when you mean literal text. ```bash prefix='a*' case 'a*b' in "$prefix"b) echo 'quoted: literal a*b matched' ;; esac case 'axb' in $prefix'b') echo 'unquoted: a*b used as a glob' ;; esac ``` Both lines print, for opposite reasons. ## Patterns are never resolved against the filesystem A related confusion: `*.txt` in a pattern position is not turned into the list of `.txt` files in the current directory first. Pathname expansion applies to command arguments, not to the pattern of a `case`. The pattern stays a pattern and is compared with the word, so the block behaves identically in an empty directory and in one full of text files. ## The practical rules 1. Quote the word (`case "$1" in`) for consistency, knowing that bash already protects you there. 2. Never quote a pattern you want to behave as a wildcard — especially not `*)`. 3. Quote the parts of a pattern that must be literal, including variables whose contents you do not control. 4. Remember that a pattern containing an unquoted variable is code, not data: whoever sets the variable decides what matches.