Se você tem my_command
assim:
#!/bin/sh
echo 'VAR1=some_value'
echo 'VAR2=other_value'
executá-lo obviamente imprime
VAR1=some_value
VAR2=other_value
Agora, source my_command
irá executar o script, no shell atual, que produzirá as atribuições como saída. Você usaria source
se my_command
não imprimisse as atribuições, mas fosse executado diretamente.
export $(my_command)
irá pegar a saída do script, e passá-lo para exportar, o que colocará as variáveis no ambiente atual do shell, mas ele só funcionará enquanto as variáveis em questão don não contém espaços em branco ou caracteres glob, pois a substituição do comando não é citada. Colocar "$(my_command)"
entre aspas realmente não ajuda, porque, em seguida, export
vê VAR1=some_value\nVAR2=other_value
como um argumento e apenas VAR1
está definido.
Note que executar export $(my_command)
ou definir variáveis de qualquer outra forma dentro de outro script não irá definir aquelas variáveis no shell pai. Se você quiser as atribuições no seu shell interativo, você deve executá-las lá, mas você pode envolver as atribuições em uma função ou source
um script que faz as atribuições.
Uma solução óbvia seria fazer o que o ssh-agent
faz e ter os comandos export
de saída do script para as variáveis que ele define. Então seria o suficiente para executar eval "$(my_command)"
.
Se não quisermos fazer isso, podemos usar set -a
antes do script para que o shell exporte automaticamente quaisquer variáveis que estejam configuradas.
Então,
$ set -a
$ eval "$(my_command)"
No Bash, podemos usar declare -p
para verificar se as variáveis são exportadas ( -x
):
$ declare -p VAR1 VAR2
declare -x VAR1="some_value"
declare -x VAR2="other_value"
Usar eval
aqui permitirá que o script produza strings citadas como VAR1="foo bar"
e elas serão tratadas corretamente. eval
também executará qualquer outra coisa do script my_command
de saídas, não apenas atribuições, mas se você não confiar em my_command
, não deverá executá-lo.