Donde es “exportar var = valor” no está disponible?

He recogido, probablemente en Usenet a mediados de la década de 1990 (!), Que el constructo

export var=value

es un Bashismo, y que la expresión portátil es

var=value
export var

He estado abogando por esto durante años, pero recientemente, alguien me desafió al respecto, y realmente no puedo encontrar ninguna documentación que respalde lo que solía ser una creencia sólida mía.

Buscar en Google "export: command not found"no parece mostrar ningún caso en el que alguien haya tenido este problema, por lo que incluso si es genuino, supongo que no es muy común.

(Los éxitos que consigo parecen ser novatos que copiar / pegar puntuacion, y terminó con 'export: command not foundo algunos de tales, o está tratando de utilizar exportcon sudoy novatos csh. Usuarios que intentan utilizar la sintaxis Bourne shell)

Ciertamente, puedo decir que funciona en OS X y en varias distribuciones de Linux, incluidas las que shestán dash.

sh$ export var=value
sh$ echo "$var"
value
sh$ sh -c 'echo "$var"'  # see that it really is exported
value

En el mundo de hoy, ¿es seguro decir que export var=valuees seguro de usar?

Me gustaría entender cuáles son las consecuencias. Si no es portátil para v7 "Bourne classic", eso es apenas más que trivialidades. Si hay sistemas de producción donde el shell realmente no puede hacer frente a esta sintaxis, sería útil saberlo.

export foo=bar

no era compatible con el shell Bourne (un antiguo shell de los años 70 del que shderivan implementaciones modernas como ash / bash / ksh / yash / zsh). Eso fue introducido por ksh.

En el shell Bourne, harías:

foo=bar export foo

o:

foo=bar; export foo

o con set -k:

export foo foo=bar

Ahora, el comportamiento de:

export foo=bar

varía de caparazón a caparazón.

El problema es que las asignaciones y los argumentos de comandos simples se analizan e interpretan de manera diferente.

El foo=baranterior es interpretado por algunas conchas como un argumento de mando y por otros como una asignación (a veces).

Por ejemplo,

a='b c'
export d=$a

se interpreta como:

'export' 'd=b' 'c'

con algunos shells ( ashversiones anteriores de zsh(en emulación sh), yash) y:

'export' 'd=b c'

en los otros ( bash, ksh).

Mientras

export \d=$a

o

var=d
export $var=$a

se interpretaría de la misma manera en todos los shells (as 'export' 'd=b' 'c') porque esa barra invertida o signo de dólar detiene los shells que lo admiten para considerar esos argumentos como asignaciones.

Si exportse cita a sí mismo o es el resultado de alguna expansión (incluso en parte), dependiendo del caparazón, también dejaría de recibir el tratamiento especial.

Consulte " ¿Se necesitan comillas para la asignación de variables locales? " Para obtener más detalles al respecto.

Sin embargo, la sintaxis de Bourne:

d=$a; export d

todos los shells interpretan lo mismo sin ambigüedad ( d=$a export dtambién funcionaría en el shell Bourne y los shells compatibles con POSIX, pero no en versiones recientes de, a zshmenos que sea en shemulación).

Puede ser mucho peor que eso. Vea, por ejemplo, esa discusión reciente sobrebash cuándo están involucradas las matrices.

(OMI, fue un error introducir esa función ).

No es un bashism sino una sintaxis compatible con POSIX. En realidad, comenzó como un kshismo hace mucho tiempo y más tarde fue adoptado por casi todos los shells basados ​​en sintaxis Bourne. La única excepción notoria es /bin/shSolaris 10 y versiones anteriores que se adhieren a la sintaxis de shell Bourne heredada. Con suerte, Solaris 11 utiliza un shell compatible con POSIX como /bin/sh.

Por cierto, exportya era un comando incorporado en el shell Bourne heredado, por lo que buscar en Google export: command not foundfue engañoso.

Aquí está el comportamiento de shell Bourne heredado cuando exportse combina con una afectación:

$ export var=22
var=22: is not an identifier

Para los nostálgicos, el código fuente de este shell Bourne original está disponible y puede compilarse para la mayoría de las distribuciones de Unix y Linux.