A atribuição de variável de shell automaticamente escapa de '['

0

Estou tentando determinar se uma string contém expressões regulares no shell ( bash ).
Especificamente, se contiver um dígito.
E enquanto isso:

$ [[ string_with[6]indice =~ [0-9] ]] && echo "True" || echo "False"

funciona como esperado, quando atribuo LHS e RHS a variáveis, algo estranho acontece:

$ STR=string_with[6]indice
$ REGEX=[0-9]
$ [[ string_with[6]indice =~ [0-9] ]] && echo "True" || echo "False"
False

Eu queria ver o que o shell usa minhas variáveis e descobri o seguinte:

$ STR=string_with[6]indice
+ STR='string_with[6]indice'
$ REGEX=[0-9]
+ REGEX='[0-9]'
$ [[ $STR =~ "$REGEX" ]] && echo "True" || echo "False"
+ [[ string_with[6]indice =~ \[0-9] ]]
+ echo False
False

De onde veio esse \ na frente de [0-9] , e por que o shell automaticamente escapa do primeiro parêntese [ in REGEX ?

    
por so.very.tired 29.10.2016 / 16:37

1 resposta

1

É porque você tem aspas duplas em torno de $REGEX . Ao combinar com o operador =~ , as seções citadas do padrão são tratadas literalmente. Ou seja, os metacaracteres de expressão regular nas seções citadas são tratados como se fossem escapados. Compare o efeito quando o padrão está entre aspas:

$ # Pattern in variable, quoted:
$ [[ $STR =~ "$REGEX" ]] && echo "True" || echo "False"
+ [[ string_with[6]indice =~ \[0-9] ]]
+ echo False
False
$ # Pattern directly in command, quoted:
$ [[ $STR =~ "[0-9]" ]] && echo "True" || echo "False"
+ [[ string_with[6]indice =~ \[0-9] ]]
+ echo False
False

com o efeito sem aspas:

$ # Pattern in variable, NOT quoted:
$ [[ $STR =~ $REGEX ]] && echo "True" || echo "False"
+ [[ string_with[6]indice =~ [0-9] ]]
+ echo True
True
$ # Pattern directly in command, NOT quoted:
$ [[ $STR =~ [0-9] ]] && echo "True" || echo "False"
+ [[ string_with[6]indice =~ [0-9] ]]
+ echo True
True

Este é um dos poucos casos em que você não quer citar uma referência de variável.

BTW, recomendo usar nomes de variáveis em minúsculas ou mistas em scripts de shell; Dessa forma, você não corre o risco de entrar em conflito com alguma variável de ambiente que tenha um significado especial para o shell ou outros programas ( $PATH é o exemplo clássico).

    
por 29.10.2016 / 20:32