Si ejecuto el siguiente archivo .sh:
#!/bin/sh -a
echo "a" | sed -e 's/[\d001-\d008]//g'
El resultado es un error:
sed: -e expresión # 1, char 18: Fin de rango inválido
Pero si ejecuto el siguiente archivo .sh:
#!/bin/sh
set -a
echo "a" | sed -e 's/[\d001-\d008]//g'
Se ejecuta sin error. ¿No se supone que el segundo código es equivalente al primero? ¿Por qué el error en el primero?
shell-script
shell
sed
options
Rodrigo
fuente
fuente
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)?LC_COLLATE=C
(oPOSIX
) para la llamada ased
solucionar el problemaPOSIXLY_CORRECT=y
en el entorno, el segundo no tienePOSIXLY_CORRECT
en el entorno. El shell desde el que invoco ambos scripts no tienePOSIXLY_CORRECT
en su entorno.echo "a" | POSIXLY_CORRECT=y sed -e 's/[\d001-\d008]//g'
reproduce tu problemaRespuestas:
Cuando se llama a bash con el nombre
sh
, hace esto :y luego establece la
POSIXLY_CORRECT
variable de shell eny
:bind_variable
llamadasbind_variable_internal
, que, si el atributo de shella
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:
sed
se invocaPOSIXLY_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:
aunque
POSIXLY_CORRECT
está configurado en el shell, no se exporta, por lo que sed se invoca sinPOSIXLY_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.fuente
/bin/sh
realidad siendo Bash). Lo mismo sucede siPOSIXLY_CORRECT
está en el entorno antes de que comience elsh
Bash: también lo transmitirá comoPOSIXLY_CORRECT=y
.POSIXLY_CORRECT
no está en el entorno cuando se inicia el shell y el script no lo configura. La cáscara lo hace. Crea una variable de entorno de la nada, lo cual es muy malo ya que lo hace en un modo donde se supone que debe estar, e intenta cumplir con los estándares.POSIXLY_CORRECT
por sí solo. No se menciona en la lista de efectos del modo POSIX y la descripción de la variable solo dice que configurarlo cambia el shell al modo POSIX, no al revés.allexport
.