Por que eu preciso 'source .profile' em todos os terminais que abro?

6

Quando alteramos algumas variáveis em ~/.profile no Ubuntu, então executamos o comando source .profile . Então a mudança é efetiva apenas neste terminal. Se abrirmos um novo terminal, temos que executar o comando source .profile novamente. Parece que diferentes terminais têm seu próprio ambiente, embora possam pertencer ao mesmo usuário.

Qual é a vantagem de fazer com que cada terminal tenha seu próprio caminho de ambiente? Parece que seria melhor se terminal diferente que pertencia ao mesmo usuário compartilhasse a mesma variável de ambiente.

    
por cainiaofei 07.01.2018 / 09:47

2 respostas

14

A razão para isso é que ~/.profile é apenas originado por shells de login. Quando você abre uma nova janela de terminal, o shell que inicia é um shell que não é de login por padrão. Se você efetuar logout e efetuar login novamente, a alteração para ~/.profile será efetiva em todos os seus terminais, porque ~/.profile é originado quando você faz login em sua sessão.

Não é o caso de janelas de terminal diferentes terem um ambiente diferente, mas o fornecimento ~/.profile executa apenas ~/.profile no shell atual (é exatamente isso que o comando source faz).

Por outro lado, uma mudança para ~/.bashrc afetará imediatamente qualquer nova janela de terminal que você abrir, ou qualquer shell Bash que você começar digitando bash , porque é originado por todos os shells Bash interativos.

    
por Zanna 07.01.2018 / 10:14
3

As variáveis de ambiente não são apenas para as preferências do usuário. Eles são um mecanismo genérico para comunicar uma variedade de informações de configuração de um processo pai a processos-filhos iniciados.

Existem inúmeros casos em que um processo define variáveis de ambiente específicas para influenciar os processos apenas iniciados. Por exemplo, um script pode redefinir deliberadamente as configurações de local para os comandos iniciados, de modo que possa analisar a saída deles. Os scripts de construção para muitos pacotes de software grandes usam invocações aninhadas de make que se coordenam entre si por meio de variáveis de ambiente. Ferramentas especializadas podem precisar alterar as condições de trabalho de outros programas que começam fazendo truques com $ LD_PRELOAD ou $ PATH.

Se algo que um usuário faz em uma janela diferente enquanto uma longa compilação está sendo executada em outro, mudaria magicamente as variáveis de ambiente de todos seus processos, a loucura e o caos poderiam resultar.

Outras variáveis de ambiente contêm informações sobre a sessão específica em que um processo é iniciado. Os programas esperam que o $ TERM descreva o conjunto de comandos do terminal (ou emulador de terminal) específico ao qual estão conectados; fazendo com que uma configuração geral por usuário impossibilitasse o acesso ao mesmo sistema com vários tipos diferentes de terminais. Mesmo se você tiver apenas um pedaço de hardware de terminal e nunca efetuar login remotamente, programas como screen dependem da configuração de um $ TERM diferente para os processos executados em sua sessão.

Uma pergunta melhor seria: por que usamos um mecanismo de comunicação de processo para subprocesso para configurações de preferência do usuário, em vez de um banco de dados por usuário?

Resposta: Porque funciona bem e os benefícios de fazer um banco de dados por usuário não são grandes o suficiente para que o trabalho de mudar tudo use em vez de variáveis de ambiente seria feito.

(Eu posso pensar em pouquíssimas configurações de preferência onde não seria alguns casos de uso onde é conveniente alterá-los apenas para executar um único script, por exemplo. Então, para não perder funcionalidade, tudo ainda precisaria ser substituível por variáveis de ambiente, o que resulta em complexidade adicional e usuários mais confusos).

Não é como se as alternativas não existissem . Por exemplo, os recursos X são por sessão de exibição, e não por processo. Mas eles são de difícil acesso para programas de linha de comando - e os programas de linha de comando geralmente precisam trabalhar para logins remotos que nem sequer têm um servidor X para se conectar.

    
por Henning Makholm 07.01.2018 / 17:06