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_CORRECTvariable de shell eny :
if (act_like_sh)
{
bind_variable ("POSIXLY_CORRECT", "y", 0);
sv_strict_posix ("POSIXLY_CORRECT");
}
bind_variablellamadas bind_variable_internal, que, si el atributo de shell aestá 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'
sedse invoca POSIXLY_CORRECT=yen su entorno, lo que hará que se queje [\d001-\d008]. (Lo mismo sucede si sed tiene la --posixopció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]\d1\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_CORRECTestá configurado en el shell, no se exporta, por lo que sed se invoca sin POSIXLY_CORRECTen el entorno y sed se ejecuta con extensiones GNU.
Si agrega export POSIXLY_CORRECTcerca de la parte superior de su segundo script, también verá quejarse.
shson iguales. Ni todos los sed son equivalentes. Cualshestas usando ¿En qué sistema operativo? y ¿Qué sed (tal vez?sed --versionsi no falla)?