Inside bash's `[[ ]]`, how do the `==` and `=~` operators differ, and what changes when you quote the right-hand side, as in `[[ $v == "$p" ]]`?

## Two matching operators, two languages The `[[ ]]` keyword gives you two ways to ask "does this value look like that?", and they speak different pattern languages. `==` (spelled `=` if you prefer) matches the left operand against the right operand interpreted as a **shell pattern** — the same wildcard language the shell uses elsewhere. `[[ $file == *.log ]]` is true for `app.log`. If the right side happens to contain no wildcard characters, the match degenerates into plain equality, which is why so many people use `==` for years without noticing it is a matcher. `=~` matches against a **POSIX extended regular expression**, the same flavour `grep -E` accepts. `[[ $s =~ ^v[0-9]+ ]]` is true for `v12`. It is a different language with different metacharacters: `*` means "zero or more of the previous item" rather than "anything", and `.` means "any character" rather than a literal dot. ## The quoting rule that decides everything The right-hand side is treated as a pattern **only where it is unquoted**. From bash 3.2 onward, any quoted portion of the right operand is matched literally. ```bash s=report.txt [[ $s == *.txt ]] # true — wildcard match [[ $s == "*.txt" ]] # false — asks whether $s is literally *.txt ``` This cuts both ways, and both directions are real bugs: - You meant equality and left the right side unquoted, so a value containing `*`, `?` or `[` silently becomes a pattern. `[[ $input == $expected ]]` is a match, not a comparison. - You meant matching and quoted the right side, so nothing ever matches and the branch is dead. This is the classic "my regex does not work" report: `[[ $s =~ "^v[0-9]+" ]]` compares against those characters literally. The left operand is never a pattern. It is always the subject being matched, and — because `[[ ]]` is a keyword — it is never word-split or glob-expanded either, so it needs no quotes for safety. ## Keeping the regex in a variable Writing a regex inline forces you to escape every character that also means something to the shell parser, and you cannot quote your way out because quotes make it literal. The standard idiom is therefore to build the regex in a variable and reference it **unquoted**: ```bash re='^v([0-9]+)\.([0-9]+)' v=v1.22.3 if [[ $v =~ $re ]]; then echo "major=${BASH_REMATCH[1]} minor=${BASH_REMATCH[2]}" fi ``` Single quotes protect the regex at assignment time, where quoting is harmless, and the unquoted expansion at match time keeps it a regex. As a bonus the pattern gets a name, which makes the condition readable and the regex reusable. ## BASH_REMATCH A successful `=~` fills the array `BASH_REMATCH`: index 0 is the entire matched text, and indexes 1..n are the parenthesised capture groups, left to right. That makes `[[ ]]` a small parser as well as a test — you can validate a string and pull its pieces out in one step, without spawning another process. Two cautions. The array is overwritten by the next successful match anywhere in the shell, so read it immediately. And it is only meaningful after a match that succeeded — check the exit status first, which the `if` above does naturally. ## Anchoring `=~` searches for the pattern **anywhere** in the string. `[[ xv12y =~ v[0-9]+ ]]` is true. If you are validating input rather than searching it, anchor both ends explicitly with `^` and `$`; a missing anchor is the most common reason a "validation" regex accepts junk with a valid substring buried in it. ## Exit statuses 0 means matched, 1 means did not match, and 2 means the regex itself was invalid — bash prints a syntax error from the regex compiler. That third case is worth handling when the pattern comes from configuration rather than from the script, because a bad pattern otherwise looks exactly like "no match" to an `if`. ## Choosing between them Use `==` with an unquoted pattern for simple shape checks: a suffix, a prefix, a wildcard. Use `=~` when you need alternation, character classes or extraction. Use `==` with a **quoted** right side whenever you mean plain equality — and make that quoting a deliberate, visible choice, since it is the difference between comparing and matching.