Eu fiz uma pesquisa na web e li vários artigos sobre o uso de variáveis no bash, incluindo o wiki , mas não consegui entender por que a execução no bash FOO_VARIABLE=foo;./test
não resulta no teste $FOO_VARIABLE
sendo foo
:
Por padrão, quando um processo é criado, ele herda um ambiente duplicado de seu processo pai, exceto pelas alterações explícitas feitas pelo pai ao criar o filho.
Também li que: Exceção de herança de variáveis de ambiente
"exceto para alterações explícitas": FOO_VARIABLE=foo ./test
- resulta no test
conhecimento do script FOO_VARIABLE
, mas por que, em primeiro lugar, não?
echo $0
-bash
cat ./test
echo $MY_TEST
MY_TEST=test$MY_TEST
echo $MY_TEST
MY_TEST=ret;./test
test
Testado no CentOS 7 e Mac OS.
ADICIONADO:
https://stackoverflow.com/questions/9772036/pass-all-variables-from-one-shell-script-to-outra
segunda maneira é a fonte (o segundo script é chamado a partir do primeiro), então não é export
necessário - por que meu caso é diferente?
ALTERAR acima: foi minha pressa e não muita atenção aos detalhes: perdi .
(ponto) na seção de sourcing, agora li: https://superuser.com/questions/176783/what-is-the-difference- entre-executando-a-bash-script-vs-sourcing-it e essa parte está tudo claro.
https://askubuntu.com/questions/26318/environment-variable-vs-shell-variable-whats-the-difference Sim, o meu é local, mas por que não é passado por herança (chamada de fork)?
No primeiro comando,
você atribui um valor à variável shell
FOO_VARIABLE
. Então você liga./test
. ComoFOO_VARIABLE
não é exportado, não é uma variável de ambiente e, portanto, não será herdada por nenhum script ou programa executado. É por isso./test
que não sabe sobre a variável.Resumindo: você define a variável shell "aqui", mas ela não estará disponível "lá" (em
./test
).No outro comando,
você define o valor de
FOO_VARIABLE
no ambiente de./test
(ou seja, você cria uma variável de ambiente./test
chamadaFOO_VARIABLE
). A variável não é definida no ambiente atual como uma variável de ambiente nem como uma variável de shell, apenas para o processo resultante da execução do./test
.Resumindo: você define a variável de ambiente "lá" (em
./test
), mas não "aqui".Se você tem uma variável existente
FOO_VARIABLE
que deseja que um script ou programa herde como uma variável de ambiente, você terá que fazerexport
isso, ou seja, criar uma variável de ambiente a partir dela:ou, mais curto
Isso define a variável localmente e a disponibiliza em qualquer processo criado (
./test
por exemplo).Porque neste ponto não é uma variável de ambiente, é uma variável shell/local. Você precisa
export MY_TEST
dele para que isso funcione. Uma alternativa seria esta:(Em Bash também simplesmente
MY_TEST=ret ./test
, mas comenv
é mais portátil entre shells.)Você pode, a propósito, verificar isso também substituindo seu
./test
porenv|grep MY_TEST
.No Bash (mas não em todos os outros shells), você também pode dizer
Executá-lo no prompt do shell será - neste caso - equivalente ao que você faria em um script.
Usar:
para verificar o que escrevi.
Supondo que
./test
fosse um script de shell (do mesmo dialeto de shell), você também poderia usar... para trazer todas as instruções
./test
para o seu shell atual. A variável shell/local também seria visível, porque você não inicia outro processo.Um subshell tem suas próprias configurações (por exemplo, opções de shell e diretório de trabalho), mas tecnicamente é executado no mesmo processo. Então não há
fork()
envolvimento. Se houverfork()
argumentos de linha de comando e variáveis de ambiente, seria a maneira de passar coisas para o outro script/executável.É diferente do caso em que um subshell herda as variáveis shell/locais do shell pai:
Aqui o subshell (dentro de
(...)
) verá a variável, mas ainda não é uma variável de ambiente.