Onde "export var = value" não está disponível?

Eu percebi - provavelmente na Usenet em meados dos anos 90 (!) - que a construção

export var=value

é um bashismo, e que a expressão portátil é

var=value
export var

Eu venho defendendo isso há anos, mas recentemente alguém me desafiou e não consigo encontrar nenhuma documentação para apoiar o que costumava ser uma sólida crença minha.

Pesquisar no Google "export: command not found"parece não trazer nenhum caso em que alguém realmente tenha esse problema; portanto, mesmo que seja genuíno, acho que não é muito comum.

(Os hits que recebo parecem ser iniciantes que copiam / colam pontuação e acabam com 'export: command not foundalgo assim, ou tentando usá export-lo sudo; e cshusuários novatos tentando usar a sintaxe do shell Bourne.)

Certamente posso dizer que ele funciona no OS X e em várias distribuições Linux, incluindo as que shestão dash.

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

No mundo de hoje, é seguro dizer que export var=valueé seguro usar?

Eu gostaria de entender quais são as consequências. Se não é portátil para a v7 "Bourne classic", isso não passa de trivial. Se houver sistemas de produção em que o shell realmente não possa lidar com essa sintaxe, seria útil saber.

export foo=bar

não era suportado pelo shell Bourne (um shell antigo dos anos 70 do qual derivam shimplementações modernas como ash / bash / ksh / yash / zsh). Isso foi introduzido por ksh.

No shell Bourne, você faria:

foo=bar export foo

ou:

foo=bar; export foo

ou com set -k:

export foo foo=bar

Agora, o comportamento de:

export foo=bar

varia de casca para casca.

O problema é que atribuições e argumentos simples de comando são analisados ​​e interpretados de maneira diferente.

O foo=baracima é interpretado por alguns shells como um argumento de comando e por outros como uma atribuição (algumas vezes).

Por exemplo,

a='b c'
export d=$a

é interpretado como:

'export' 'd=b' 'c'

com algumas conchas ( ash, versões mais antigas de zsh(na emulação sh) yash) e:

'export' 'd=b c'

nos outros ( bash, ksh).

Enquanto

export \d=$a

ou

var=d
export $var=$a

seria interpretado da mesma forma em todas as conchas (as 'export' 'd=b' 'c') porque essa barra invertida ou cifrão interrompe as conchas que a suportam a considerar esses argumentos como atribuições.

Se exportele próprio for citado ou resultar de alguma expansão (mesmo em parte), dependendo da concha, também deixaria de receber o tratamento especial.

Consulte " São necessárias cotações para atribuição de variável local? " Para obter mais detalhes sobre isso.

A sintaxe Bourne:

d=$a; export d

é interpretado da mesma forma por todos os shells sem ambiguidade ( d=$a export dtambém funcionaria no shell Bourne e nos shells compatíveis com POSIX, mas não nas versões recentes, zshexceto em shemulação).

Pode ficar muito pior que isso. Veja, por exemplo, uma discussão recente sobrebash quando matrizes estão envolvidas.

(OMI, foi um erro introduzir esse recurso ).

Não é um basismo, mas uma sintaxe compatível com POSIX. Na verdade, ele começou como um kshismo há muito tempo e foi posteriormente adotado por quase todos os shells Bourne baseados em sintaxe. A única exceção notória é /bin/shno Solaris 10 e mais antigo, que segue a sintaxe herdada do shell Bourne. Felizmente, o Solaris 11 usa um shell compatível com POSIX como /bin/sh.

A propósito, exportjá era um comando embutido no shell herdado de Bourne, pelo que pesquisar no Google export: command not foundera enganador.

Aqui está o comportamento do shell Bourne herdado quando exportcombinado com uma afetação:

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

Para os nostálgicos, o código fonte deste shell Bourne original está disponível e pode ser compilado para a maioria das distribuições Unix e Linux.