BASH_ENV
só será definido por meio do ambiente ou outro script originado durante a inicialização. Para um shell não interativo, ele estará apenas tentando obter arquivos adicionais se esse shell também for um shell de login. (nesse caso, ele lerá ~/.bash_profile
, ~/.bash_login
e ~/.profile
... mas, se estiver fazendo isso, você não estará tendo problemas)
O primeiro lugar para procurar é o ambiente no qual a subshell está sendo invocada.
- Uma variável
BASH_ENV
exportada será transmitida. Tenha em mente que isso pode estar enterrado em um arquivo de origem. - Ele pode ser inserido como um parâmetro na mesma linha que chama o script, ou seja,
BASH_ENV=blah /path/to/somecommand.sh
. Isso se destaca como um polegar dolorido, então você provavelmente teria pego isso.
Se ele estiver sendo definido depois que você fizer login, mas não conseguir descobrir onde, talvez seja necessário analisar o que é responsável pela construção do ambiente de login.
-
Todos os arquivos usuais que são originados por um shell de login.
man bash
para a lista exaustiva. -
PAM : Como o freiheit sugeriu nos comentários, verifique
/etc/security/pam_env.conf
e todos os arquivos adicionais referenciados porpam_env.so
. Outros módulos PAM também podem ser responsáveis, mas se suas configurações do PAM forem idênticas, provavelmente não é o caso. -
sshd : Ele irá verificar os seguintes arquivos, na ordem:
-
~/.ssh/environment
(antes de mudar para o diretório inicial; somente sePermitUserEnvironment
estiver ativado emsshd_config
) -
~/.ssh/rc
(depois de mudar para o diretório inicial; sempre) -
/etc/ssh/sshrc
(se~/.ssh/rc
não estiver presente)
-
Observação: sshd
também verificará environment=value
linhas no arquivo de chaves autorizadas do usuário (se PermitUserEnvironment
estiver ativado), mas não fica claro na página do manual em que essa etapa se enquadra na sequência acima. / p>