Por que tenho que `source .profile` em todos os terminais que abro?

Quando alteramos alguma variável no ~/.profileUbuntu, executamos o comando source .profile. Então a mudança é efetiva apenas neste terminal. Se abrirmos um novo terminal, precisamos executar o comando source .profilenovamente. Portanto, 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 um terminal diferente que pertencesse ao mesmo usuário compartilhasse a mesma variável de ambiente.

A razão para isso é que ela ~/.profileé fornecida apenas por shells de login. Quando você abre uma nova janela de terminal, o shell que é iniciado é um shell sem login por padrão. Se você efetuar logoff e logon novamente, a alteração ~/.profileserá efetiva em todos os seus terminais, porque ~/.profileé originada quando você faz logon na sua sessão.

Não é o caso de que diferentes janelas de terminal tenham um ambiente diferente, mas esse sourcing ~/.profileé executado apenas ~/.profileno shell atual (é exatamente isso que o sourcecomando faz).

Por outro lado, uma alteração em ~/.bashrcafetará imediatamente qualquer nova janela de terminal que você abrir ou qualquer shell do Bash que você digitar bash, porque é originada por todos os shells interativos do Bash.

As variáveis ​​de ambiente não são apenas para 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 para processos filhos que ele inicia.

Existem inúmeros casos em que um processo define variáveis ​​de ambiente específicas para influenciar apenas os processos iniciados. Por exemplo, um script pode deliberadamente redefinir as configurações de localidade 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 makedessa coordenada entre si por meio de variáveis ​​de ambiente. As ferramentas especializadas podem precisar alterar as condições de trabalho de outros programas iniciados, fazendo truques com $ LD_PRELOAD ou $ PATH.

Se algo que um usuário faz em uma janela diferente enquanto uma compilação longa está sendo executada em outra, apenas altera magicamente as variáveis ​​de ambiente de todos os seus processos pelas costas, resultam em loucura e caos.

Outras variáveis ​​de ambiente contêm informações sobre a sessão específica em que um processo é iniciado. Os programas esperam que $ TERM descreva o conjunto de comandos do terminal específico (ou emulador de terminal) ao qual estão conectados; fazer com que uma configuração geral por usuário impossibilite o logon no mesmo sistema com vários tipos diferentes de terminais. Mesmo que você tenha apenas um hardware de terminal e nunca efetue logon remotamente, programas como o screendependem de definir 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ências do usuário, em vez de um banco de dados por usuário?

Resposta: Como funciona bem o suficiente e os benefícios de criar um banco de dados por usuário não são grandes o suficiente para que o trabalho de mudar tudo para usar isso em vez de variáveis ​​de ambiente seja realizado.

(Posso pensar em muito poucas configurações de preferência em que não haveria casos de uso em que seria conveniente alterá-las apenas para executar um único script, por exemplo. Portanto, para não perder a funcionalidade, tudo ainda precisará ser substituído por variáveis ​​de ambiente, o que resulta em maior complexidade e usuários mais confusos).

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