Cuando se llama a bash con el nombre sh
, hace esto :
if (shell_name[0] == 's' && shell_name[1] == 'h' && shell_name[2] == '\0')
act_like_sh++;
y luego establece la POSIXLY_CORRECT
variable de shell eny
:
if (act_like_sh)
{
bind_variable ("POSIXLY_CORRECT", "y", 0);
sv_strict_posix ("POSIXLY_CORRECT");
}
bind_variable
llamadas bind_variable_internal
, que, si el atributo de shell a
está activado en ese momento (que sería si invocara el shell con -a
), marca la variable de shell como exportada .
Entonces en tu primer guión:
#!/bin/sh -a
echo "a" | sed -e 's/[\d001-\d008]//g'
sed
se invoca POSIXLY_CORRECT=y
en su entorno, lo que hará que se queje [\d001-\d008]
. (Lo mismo sucede si sed tiene la --posix
opción).
En GNU sed, es un código de escape para el carácter cuyo valor numérico en base 10 es NNN , pero en modo POSIX, esto es deshabilitado dentro de una expresión entre corchetes, por lo que , literalmente significa los caracteres , etc., siendo el rango de a . En orden de códigos de caracteres, viene antes (y el rango incluye todos los dígitos excepto cero, más todas las letras mayúsculas, más algunos caracteres especiales). Sin embargo, en la configuración regional que estaba utilizando, se ordena antes , por lo que el rango no es válido.\dNNN
[\d001-\d008]
\
d
1
\
1
\
en_US.UTF-8
\
1
En tu segundo guión:
#!/bin/sh
set -a
echo "a" | sed -e 's/[\d001-\d008]//g'
aunque POSIXLY_CORRECT
está configurado en el shell, no se exporta, por lo que sed se invoca sin POSIXLY_CORRECT
en el entorno y sed se ejecuta con extensiones GNU.
Si agrega export POSIXLY_CORRECT
cerca de la parte superior de su segundo script, también verá quejarse.
sh
son iguales. Ni todos los sed son equivalentes. Cualsh
estas usando ¿En qué sistema operativo? y ¿Qué sed (tal vez?sed --version
si no falla)?