A team standardises on `[[ ]]` for every bash script and stops requiring quotes inside conditionals, on the grounds that `[[ ]]` makes quoting unnecessary. Which failure modes does that genuinely remove, and where does dropping the quotes still bite?

## What the keyword actually guarantees The rule "`[[ ]]` means you do not have to quote" is half true, and the half that is false is the dangerous half. The true half: `[[` is a shell reserved word, so the shell parses the whole construct and evaluates the operands internally instead of building an argument list for a command. Two expansion steps that apply to ordinary commands therefore do not happen inside it — **word splitting** and **pathname expansion**. That is real: ```bash f="my file.txt" [[ -f $f ]] # correct: one operand, spaces and all [ -f $f ] # [: my: binary operator expected x="" [[ -z $x ]] # correct: true [ -n $x ] # true! test sees one argument, "-n", which is non-empty ``` The entire family of "unary operator expected" and "too many arguments" failures disappears, along with the working-directory-dependent glob accidents. If that were the whole story, the team's rule would be fine. ## Gap 1: the right-hand side is still a pattern `==`, `!=` and `=~` treat their right operand as a pattern or a regex while it is unquoted. Splitting and globbing were suppressed; *matching* was not — it is the operator's own semantics. ```bash allowed='a*' user=admin [[ $user == $allowed ]] # TRUE — pattern match, not equality [[ $user == "$allowed" ]] # false — literal comparison ``` This is the worst kind of bug: it appears in authorization checks, allow-lists and confirmation prompts, wherever a value from configuration or from an argument reaches the right-hand side. Nothing errors, nothing logs, and the condition is simply more permissive than it reads. A team rule that says "no quotes needed in conditionals" removes the one visual cue that would have distinguished "compare" from "match". The converse bites too: a quoted regex matches literally and the branch is silently dead. ## Gap 2: `-eq` evaluates arithmetic, it does not validate Inside `[[ ]]` the numeric operators put their operands through arithmetic evaluation. In that context a bare word is a **variable name**, and an unset or empty variable is **0**: ```bash x="" [[ $x -eq 0 ]] # true [[ abc -eq 0 ]] # true — abc is an unset variable, therefore 0 ``` So a guard like `if [[ $count -eq 0 ]]; then skip; fi` treats "the variable was never set" and "the command produced nothing" as a legitimate zero. `[ "$x" -eq 0 ]` at least fails loudly with `integer expression expected` — the older construct is stricter here. If the value came from outside the script, validate its shape first, for instance with a regex match, rather than trusting a numeric operator to reject it. ## Gap 3: the habit does not travel Quoting is a whole-script discipline, and `[[ ]]` is an island. The same author who learned that `$file` is safe inside the brackets writes: ```bash [[ -f $file ]] && cp $file $dest # the cp splits on spaces for f in $files; do ... # splits and globs rm $tmpdir/* # nothing to do with conditionals ``` The conditional was the *only* place the exemption applied. A rule phrased as "you do not need quotes" trains the wrong generalisation; a rule phrased as "`[[ ]]` suppresses splitting on its operands, and we quote anyway" trains the right one. And the moment a script needs a POSIX `#!/bin/sh` interpreter, `[[` is not available at all and every unquoted expansion in the file is live again. ## Why the linter will not save you ShellCheck's unquoted-expansion warning SC2086 is deliberately **not** emitted inside `[[ ]]`, because splitting genuinely cannot happen there — the tool is right about the mechanism. It also cannot know whether an unquoted right operand of `==` was meant as a pattern; both readings are valid shell. So the two gaps above are precisely the ones static analysis is least able to flag, which makes them a review-discipline problem rather than a tooling problem. ## The policy that actually works Use `[[ ]]` in bash scripts — it is strictly safer than `[ ]` and more capable. Then keep three rules: 1. Quote by default anywhere, including inside `[[ ]]`; the cost is two characters. 2. Leaving the right side of `==` or `=~` unquoted is a **deliberate, commented** choice meaning "this is a pattern". 3. Never let a numeric operator serve as input validation; check the shape first. The useful framing in a review is that `[[ ]]` removes a class of *syntax* failures — noisy, immediate, easy to find — while the remaining risks are *semantic*: silent, permissive, and discovered in production.