Os aplicativos GUI não herdam o PATH dos aplicativos de console pai [fechado]

Question

No Gnome, os aplicativos GUI não herdam o PATH do processo do shell que os inicia? Aparentemente, os aplicativos GUI veem apenas o PATH especificado em ~/.profile . Não há problemas com aplicativos de console, no entanto.

Se eu iniciar os aplicativos GUI disponíveis no atual PATH de minhas sessões Bash, eles não serão iniciados. Por exemplo:

• O Thunderbird não consegue encontrar a biblioteca libxpcom.so (ela está em sua pasta). No entanto, o comando which localiza essa biblioteca (porque a pasta está em PATH ).
• O Firefox falha com "Não foi possível encontrar o tempo de execução do Mozilla."

Adicionar PATH a LD_LIBRARY_PATH não corrige o problema.

No entanto, se eu também:

1. defina o PATH em ~/.profile e reinicie a sessão do Gnome;
2. ou alterne para a pasta de um aplicativo antes de iniciá-lo;

posso executar qualquer aplicativo gráfico da minha sessão Bash sem problemas. De fato, no momento, recorri ao uso de um script que emula o segundo procedimento.

Qual é o problema? Devo usar um lançador para aplicativos GUI, talvez?

Eu não quero colocar meu personalizado PATH em ~/.profile , daí esta questão.

Obrigado pela sua atenção.

Ambiente:

• Debian GNU / Linux: 6.0.7
• Versão do Gnome: 2.30.2

Editar : Eu não sei como o Gnome é iniciado: eu instalei o Debian com GUI e ele inicia o Gnome por padrão depois de uma tela de login gráfica.

O Bash é iniciado a partir do Painel do Gnome com o comando "gnome-terminal --full-screen".

Editar 2:

Graças à sugestão de Bob, eu tentei executar bash --norc - ou seja: Bash com a configuração padrão - e então adicionar o caminho para o Thunderbird e Firefox manualmente e - ofegar! - agora ambos os aplicativos são lançados corretamente. Como posso solucionar esse problema? Meu ~/.bashrc é apenas um monte de adição a PATH . Além disso, o comando which resolve os firefox e thunderbird fine. Talvez existam bibliotecas que se escondem no meu PATH ? Em qualquer caso, LD_LIBRARY_PATH está sempre vazio.

Acho que uma solução poderia ser ter um script de inicialização para cada aplicativo de GUI, como um comentador sugeriu.

    

Answer 1

Grande parte da confusão sobre isso ocorre porque varia de acordo com a distribuição do Linux. Em geral ...

• / etc / profile é originado apenas na inicialização.
• / etc / profile sources /etc/profile.local, se existir.
• /root/.bashrc é originado ...
  • Na inicialização, depois de / etc / profile.
  • Ao abrir uma nova sessão de terminal.
• Somente comandos inseridos em uma linha de comando de sessão de terminal farão uso do PATH definido em /root/.bashrc.
• Scripts e programas executados por uma GUI como o Gnome usam o PATH definido em / etc / profile.
• Como o / etc / profile executa o /etc/profile.local, se existir, as alterações e adições ao PATH geralmente são feitas da melhor forma. Lembre-se de 'exportar o PATH' para que todos os subshells o vejam.

Eu sei que este é o comportamento no Puppy Linux 5.2.8 Lupu que é baseado no Ubuntu 10.04 e a pesquisa indica que é comum, pelo menos para muitas distribuições baseadas no Debian como o Ubuntu.

Você poderia pensar que um PATH definido em $ HOME / .profile (script de usuário análogo ao script do sistema / etc / profile) funcionaria para sessões não terminais como o Gnome, mas não funciona. A GUI do Xwindows e vários gerenciadores de exibição, etc., como o Gnome, são executados paralelamente às sessões de terminal, portanto, não herdam as configurações do $ HOME / .bashrc.

Parece que quase todos os programas assumem a responsabilidade de redefinir o PATH, se necessário. O comando a seguir irá revelar literalmente dezenas ou até centenas de arquivos contendo 'PATH =' ...

grep -r 'PATH=' /etc/*

Ilustração de relevância para a questão

A hierarquia atual do processo na minha máquina é mostrada abaixo na saída editada do comando ...

ps -efH | cut -c49-126
----------------------
/bin/busybox init
  /bin/sh /usr/bin/xwin
    /usr/bin/xinit /root/.xinitrc -- -br -nolisten tcp
      X :0 -br -nolisten tcp
      openbox
        /bin/ash /sbin/pup_event_frontend_d
          sleep 2
  /usr/local/apps/ROX-Filer/ROX-Filer -p /root/Choices/ROX-Filer/PuppyPin
    roxterm
      gnome-pty-helper
      -sh
      -sh
      -sh
      -sh
      -sh
      -sh
        ps-FULL -efH
        cut -c49-126
    geany

• A primeira linha da saída seria apenas 'init' na maioria dos sistemas, mas Filhote de cachorro substitui muitos comandos como este com 'busybox'.
• Observe que o 'xwin', que inicia o subsistema Xwindows, é executado por 'init'.
• Descendo, observe que o ROX-Filer está funcionando como o gerenciador de desktop e está no mesmo nível de 'xwin', com 'roxterm' sendo o analógico para 'gnome-terminal' e os processos '-sh' sendo os vários sessões de terminal bash eu tenho aberto em suas abas.
• Geany é o editor da GUI que está em execução e também está no mesmo nível do Xwin e do ROX-Filer.

As variáveis de ambiente exportadas, como o PATH, são herdadas apenas do processo que as iniciou (por exemplo, "processo pai"). A saída ps não mostra isso, mas / etc / profile (e /etc/profile.local) é um dos muitos scripts lidos durante o processo de inicialização 'init', assim o 'xwin' pode ver o PATH definido nele. No entanto, como .bashrc não é um desses scripts, o conjunto PATH não pode ser visto por outros programas GUI.

Programas GUI seriam capazes de ver o PATH .bashrc se você os iniciou a partir de uma linha de comando bash.