In bash, `[[ $file == *.txt ]]` and `[[ $file == "*.txt" ]]` behave differently. What does quoting the right-hand side of `==` inside `[[ ]]` do, and where else in bash does quoting turn a pattern into a literal string?

## The right-hand side is a pattern `[[ ]]` is a shell keyword, not a command, so bash parses its contents specially. For the `==` and `!=` operators, the word on the right is treated as a **pattern** — the same pattern language used for filename globbing, though here it is matched against a string rather than against the filesystem. `*` matches any sequence, `?` matches one character, `[abc]` matches a character class. ```bash file=report.txt [[ $file == *.txt ]] # true - glob match [[ $file == "*.txt" ]] # false - literal match against the text *.txt [[ $file == '*.txt' ]] # false - same, single quotes are equally literal ``` Quoting is the switch between those two modes, and the switch is per-character: quoting *part* of the pattern makes only that part literal. ```bash suffix='.txt' [[ $file == *"$suffix" ]] # true - * is a wildcard, the suffix is literal text [[ $file == "*$suffix" ]] # false - the * is literal now too ``` That partial form is the idiomatic one when the pattern is built from a variable. If the variable might itself contain `*` or `?` and you want those treated as data, quote it: `[[ $name == "$user_input" ]]` is an exact-equality test, whereas `[[ $name == $user_input ]]` lets the user's value act as a pattern — a real and easily missed behaviour change. ## The left-hand side is different Inside `[[ ]]` no word splitting and no pathname expansion is performed on expansions, so the left-hand side does not need quotes to be safe: ```bash f='My Report.txt' [[ $f == 'My Report.txt' ]] && echo match # works, unquoted, despite the space ``` This is one of the few places in bash where an unquoted expansion is genuinely safe. Many teams still quote it for consistency, which is harmless — quoting the left side never changes the meaning. ## case works the same way `case` labels are patterns from the same language, and quoting them has the same effect: ```bash case $file in "*.txt") echo 'the file is literally named *.txt' ;; *.txt) echo 'any .txt file' ;; esac ``` The word after `case` is likewise not word-split or globbed, so `case $file in` is safe unquoted for the same reason the left side of `==` is. ## The regex operator `=~` matches an extended regular expression, and since bash 3.2 quoting a part of the right-hand side forces that part to be matched literally: ```bash s='aab' [[ $s =~ a+b ]] # true - a+ is a regex quantifier [[ $s =~ "a+b" ]] # false - looks for the literal three characters a+b ``` This surprises people who quote out of habit and then wonder why their regex stopped working. The usual convention is to keep the regex in a variable and use it unquoted, which also sidesteps the parsing pitfalls of writing a regex inline: ```bash re='^[0-9]{3}-[0-9]{4}$' [[ $phone =~ $re ]] && echo 'valid' ``` Conversely, when you want a user-supplied string matched *literally*, quote it deliberately so their metacharacters cannot act as pattern syntax. ## Why this matters in review The failure mode is quiet. A guard like `[[ $branch == "release/*" ]]` never fires and the release-only step is silently skipped in every run — no error, no exit status anyone checks, just a branch of the script that is dead. Reading it, the quotes look like good hygiene, which is exactly what makes the bug durable. When you see a `[[ ]]` comparison, ask whether the right-hand side is meant as data or as a pattern, and make the quoting say so. ## Rule of thumb Quote the right-hand side when you mean an exact string; leave the wildcard characters unquoted and quote only the interpolated data when you mean a pattern. `case` labels follow the identical rule, and `=~` operands invert your instincts, so treat them deliberately rather than by habit.