A única maneira de corresponder uma string explícita é citá-la:
[[ $var =~ 'quux' ]]
Mesmo que a string contenha caracteres especiais (especiais para o shell [a] )
sem o shell expandindo ou interpretando-os [b] :
$ var='^abcd'
$ [[ $var =~ '^ab' ]] && echo yes || echo no
yes
Se precisarmos permitir (shell) caracteres especiais e permitir que o shell os interprete como uma expressão regular, eles devem ser desclassificados.
$ var='abcd'
$ [[ $var =~ ^ab ]] && echo yes || echo no
yes
Mas as strings sem aspas criam novos problemas, como os espaços:
$ var='ab cd'
$ [[ $var =~ ^ab cd ]] && echo yes || echo no
bash: syntax error in conditional expression
bash: syntax error near 'cd'
Para resolver isso, precisamos ainda citar caracteres especiais:
$ var='ab cd'
$ [[ $var =~ ^"ab cd" ]] && echo yes || echo no
yes
$ [[ $var =~ ^ab\ cd ]] && echo yes || echo no
yes
Outros exemplos:
[[ "a b" =~ ^a\ b$ ]] && echo yes
[[ "a|b" =~ ^a\|b$ ]] && echo yes
[[ "a&b" =~ ^a\&b$ ]] && echo yes
Armazenar o regexp dentro de uma variável evita todos os problemas de citação.
$ regex='^a b$'
$ [[ "a b" =~ $regex ]] && echo yes
yes
[a]
Lista de caracteres especiais do shell ( |
&
;
(
)
<
>
space
tab
newline
).
[b]
Isso é verdade desde a versão bash bash-3.2-alpha (no título "3. Novos recursos no Bash") :
f. Quoting the string argument to the [[ command's =~ operator now forces
string matching, as with the other pattern-matching operators.
Cópia de descrição estendida do FAQ do bash :
E14) Why does quoting the pattern argument to the regular expression matching conditional operator (=~) cause regexp matching to stop working?
In versions of bash prior to bash-3.2, the effect of quoting the regular expression argument to the [[ command's =~ operator was not specified. The practical effect was that double-quoting the pattern argument required backslashes to quote special pattern characters, which interfered with the backslash processing performed by double-quoted word expansion and was inconsistent with how the == shell pattern matching operator treated quoted characters.
In bash-3.2, the shell was changed to internally quote characters in single-
and double-quoted string arguments to the =~ operator, which suppresses the
special meaning of the characters special to regular expression processing
(.',
[', \',
(', ),
*', +',
?', {',
|', ^', and
$') and forces
them to be matched literally. This is consistent with how the '==' pattern
matching operator treats quoted portions of its pattern argument.
Since the treatment of quoted string arguments was changed, several issues
have arisen, chief among them the problem of white space in pattern arguments
and the differing treatment of quoted strings between bash-3.1 and bash-3.2.
Both problems may be solved by using a shell variable to hold the pattern.
Since word splitting is not performed when expanding shell variables in all
operands of the [[ command, this allows users to quote patterns as they wish
when assigning the variable, then expand the values to a single string that
may contain whitespace. The first problem may be solved by using backslashes
or any other quoting mechanism to escape the white space in the patterns.
Perguntas relacionadas:
Usando uma variável em um regex