De acordo com um comentário no Fedora, Adicionando ~ / .local / bin ao padrão PATH , essa foi uma mudança específica do Fedora na configuração bash , alguns anos atrás.
A mudança foi feita no RPM (não no upstream), e não documentado.
Eu acho que o gnome-terminal pode ter modificado a variável PATH environ ao invocar o shell.
Especificamente, $HOME/.local/bin:$HOME/bin será sempre anexado a PATH .
Eu fiz o seguinte experimento para demonstrar isso:
sh . Dessa forma, bash deve ser chamado em sh -way e não é um shell de login. /etc/profile , $HOME/.bash_profile , $HOME/.bashrc não
se originado, nós renomeamos esses arquivos temporariamente. (Na verdade, esses arquivos NÃO devem
já adquiridos, já que estamos invocando um não-login sh .) Agora, abra uma nova janela do terminal gnome e execute echo $PATH . Aqui está o que eu tenho:
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/naitree/.local/bin:/home/naitree/bin
Eu não entendo porque os dois últimos caminhos apareceram em PATH .
Com base nesse fato, acho que as seguintes explicações possíveis existem:
PATH é herdado do processo pai, que nesse caso é o gnome-terminal-server . PATH é modificado em algum script que é originado misteriosamente por sh em algum momento. PATH é modificado quando o gnome-terminal-server se separa do subprocesso. Agora, acho que descartei as possibilidades # 1 e # 2:
cat /proc/$PPID/environ onde $PPID é o PID de gnome-terminal-server mostra que
sua variável PATH é /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin , que não contém o que estamos procurando. No sh que acabamos de abrir, execute export -n PATH e sh -x , não consigo ver nada
obtenha origem durante o processo de inicialização deste novo sh . E seu PATH está limpo:
/usr/local/bin:/usr/bin
O que me deixa a última possibilidade.
Eu perdi alguma coisa? O gnome-terminal é o culpado pelo misteriosamente modificado PATH ?
Atualização:
Acabei de experimentar sh -x como o comando personalizado. Ao abrir o gonme-terminal, não vi nada ter origem. Mas, echo $PATH diz que $HOME/.local/bin e $HOME/bin estão lá.
Aqui estão as informações relacionadas à distribuição:
Update2:
Eu apenas tentei:
echo "$PATH" no início de ~/.bashrc . bash -x . Com base na saída de depuração, observei que ~/.bashrc é o ponto inicial do fornecimento de script. Mas o $HOME/.local/bin e o $HOME/bin já estão lá em PATH antes disso.
De acordo com um comentário no Fedora, Adicionando ~ / .local / bin ao padrão PATH , essa foi uma mudança específica do Fedora na configuração bash , alguns anos atrás.
A mudança foi feita no RPM (não no upstream), e não documentado.
Eu tive um problema semelhante, com o terminal PATH sendo inicialmente definido como /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin .
Tendo verificado todos os suspeitos usuais, ~/.bashrc , ~/.bash_profile , /etc/bashrc , /etc/profile , recorri a alterar a configuração DefaultEnvironment em /etc/systemd/system.conf e /etc/systemd/user.conf . Mas ainda acabei com /usr/local/... no PATH .
Por acaso, me deparei com uma referência a pam_env enquanto tentava descobrir onde o ambiente de caminho estava sendo definido. Então, adicionei a seguinte linha a /etc/security/pam_env.conf :
PATH DEFAULT=/bin:/sbin
Após o login novamente, o terminal shell PATH ficou livre dos traços locais.
Tenho certeza de que os padrões vêm de pam_env , já que após alterar a configuração do systemd, nem o PID 1 nem o systemd --user processam os caminhos locais no ambiente, mas gnome-terminal-server o fez.
O Linux moderno está se tornando um pesadelo de configuração.
Eu percebo que isso não é uma resposta para a questão do OP. Mas parecia bastante relacionado para valer a pena mencionar.
Tags gnome-terminal shell path