Se eu executar o seguinte arquivo .sh:
#!/bin/sh -a
echo "a" | sed -e 's/[\d001-\d008]//g'
O resultado é um erro:
sed: -e expressão #1, char 18: fim de intervalo inválido
Mas se eu executar o seguinte arquivo .sh:
#!/bin/sh
set -a
echo "a" | sed -e 's/[\d001-\d008]//g'
Ele roda sem erro. O segundo código não deveria ser equivalente ao primeiro? Por que o erro no primeiro?
Quando o bash é chamado com o nome
sh
, ele faz isso :e depois define a
POSIXLY_CORRECT
variável do shell paray
:bind_variable
callsbind_variable_internal
, que, se o atributo shella
estiver ativado no momento (o que aconteceria se você invocasse o shell com-a
), marca a variável shell como exportada .Então, no seu primeiro script:
sed
é invocadoPOSIXLY_CORRECT=y
em seu ambiente, o que o fará reclamar do[\d001-\d008]
. (A mesma coisa acontece se o sed tiver a--posix
opção.)No GNU sed, é um código de escape para o caractere cujo valor numérico na base-10 é NNN , mas no modo POSIX, isso é desabilitado dentro de uma expressão de colchetes, então , significa literalmente os caracteres , , etc., com o intervalo sendo de para . Na ordem dos códigos de caracteres, vem antes (e o intervalo inclui todos os dígitos, exceto zero, mais todas as letras maiúsculas e alguns caracteres especiais). Na localidade que você estava usando, classifica antes de , portanto, o intervalo é inválido.
\dNNN
[\d001-\d008]
\
d
1
\
1
\
en_US.UTF-8
\
1
No seu segundo script:
mesmo que
POSIXLY_CORRECT
esteja definido no shell, ele não é exportado, então o sed é invocado foraPOSIXLY_CORRECT
do ambiente e o sed é executado com extensões GNU.Se você adicionar
export POSIXLY_CORRECT
próximo ao topo do seu segundo script, você também verá sed reclamação.