Do not quote the right side of =~
SC2076: quoting the pattern in `[[ $var =~ "pat" ]]` turns it into a literal string match. Use an unquoted pattern or a variable.
Problem
Bash treats the right side of `=~` as a regex only when it is unquoted. `[[ "$x" =~ "^abc" ]]` matches the literal five characters `^abc`, not "starts with abc".
Bad
[[ "$version" =~ "^[0-9]+\." ]]Good
pat='^[0-9]+\.'
[[ "$version" =~ $pat ]]Explanation
Store the pattern in a variable to keep it readable and avoid quote-escaping issues. The variable itself should be unquoted on the right of `=~`.
When It Matters
Inside [[ $x =~ pattern ]] the right-hand side is a regular expression, but quoting it turns it into a literal string. So [[ "$file" =~ "\.log
quot; ]] stops meaning "ends with .log" and starts meaning "contains the six characters backslash dot l o g dollar" — which never matches anything. The bug is dangerous in validation code: a quoted pattern that never matches turns a whitelist check into a permanent reject, or, with negation, turns a blacklist check into a permanent accept.Second Example
Note
Storing the pattern in a variable and expanding it unquoted is the recommended style: the quoting on the assignment protects it from globbing without making it literal.
Exceptions
If you genuinely want a literal substring test, quoting is the right way to get it — but then say so with == instead: [[ $x == *"literal"* ]] expresses the intent more clearly than a regex whose metacharacters have been disabled. Reserve =~ for actual patterns.
Faq
Q
How do I match a literal dot with =~?
A
Escape it in the unquoted pattern: [[ $f =~ \.log$ ]], or put the pattern in a variable as re='\.log
#39; and use [[ $f =~ $re ]].Q
Why is the variable form recommended?
A
It keeps the pattern out of the parser’s way. Quoting on assignment prevents globbing and word splitting, and expanding unquoted inside [[ ]] preserves regex meaning.
Q
Is =~ available in sh?
A
No. [[ ]] and =~ are Bash extensions. In POSIX sh use a case statement or an external grep.