O GNU Screen não herdará meu PATH no 10.5.8

10

Eu uso a tela diariamente para minhas necessidades de terminal e estou muito feliz com isso. Recentemente, porém, fiz algumas atualizações em meus arquivos de configuração bash e notei que estava definindo vários PATH elements ( PATH , MANPATH , INFOPATH , etc) em 2 locais. Eu modifiquei os arquivos para serem o que deveriam ser e agora todas as minhas variáveis de ambiente são definidas uma vez em .bash_profile . Aqui está meu problema.

Aparentemente, a razão pela qual eu estava colocando-os em dois lugares foi por causa da tela. a tela parece executar apenas .bashrc e não parece herdar minhas PATH ou quaisquer outras variáveis de ambiente corretamente do meu bash shell original. Como só executa .bashrc e agora defino minhas variáveis apenas em .bash_profile , recebo uma PATH incompleta.

Minha pergunta, então, é como colocar minhas variáveis de ambiente na tela sem a duplicação. Ler o Bash docs parece indicar que ele pode ser o tipo de casca que a tela usa para efetuar login, ou seja, um shell interativo sem login , mas não consegui descobrir como forçar a tela a usar um tipo específico de shell, apenas o shell a ser usado via -s /bin/bash .

Você pode ler meus arquivos de configuração em minha página do GitHub . Este é o commit commit que quebrou a tela .

EDITAR: estou usando Screen version 4.00.03 (FAU) 23-Oct-06 e tenho a tendência de invocá-lo por screen -h 50000

EDITAR: Agora consegui testar isso no Cygwin ( CYGWIN_NT-5.1 1.7.1(0.218/5/3) i686 , Screen version 4.00.03 (FAU) 23-Oct-06 ) e ele exibe um comportamento diferente do meu Mac.

O comportamento específico que descobri agora é que no Cygwin as alterações que faço no PATH no .bash_profile são duplicadas ao entrar na tela e, em seguida, a criação sucessiva de janelas de tela não duplica o caminho, mas é reutilizada. .bash_profile.

Para ilustrar o comportamento do qual estou falando:

Saída de um terminal novo:

...

PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack

MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man

Aliases:
alias ..='cd ..'
alias ...='cd ../..'

...

[~]$

Saída da primeira chamada da tela:

[~]$ screen -h 50000 -s -/bin/bash

...

PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack

MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man:/home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/ssl/man

Aliases:
alias ..='cd ..'
alias ...='cd ../..'

...

[~]$

Chamadas subseqüentes para C-a c :

...

PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack

MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man:/home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/ssl/man

Aliases:
alias ..='cd ..'
alias ...='cd ../..'

...

[~]$

Você pode ver

    
por Tim Visher 27.02.2010 / 17:22

6 respostas

15

tela e variáveis de ambiente

Por padrão, a tela passa para seus shells (e outros processos) quaisquer variáveis de ambiente que tivessem quando a sessão foi iniciada (ou seja, a reconexão não altera quais variáveis de ambiente são dadas a novos shells). Mas como os arquivos de configuração screen e shells 'normalmente alteram as variáveis de ambiente, há muitos lugares onde alterações inesperadas podem ser introduzidas. Existem algumas variáveis, como TERM , que a tela quase sempre muda, mas estas geralmente são necessárias para a funcionalidade que a tela oferece. / p>

Digamos que nem a configuração do seu shell, nem a configuração do screen irá modificar uma variável chamada FOOBAR (bastante provável, apesar de tudo). Se você iniciar uma sessão com FOOBAR=foo screen , todos os shells criados nessa sessão terão uma variável de ambiente chamada FOOBAR com um valor de foo .

As coisas ficam mais complicadas para variáveis que exibem ou que seu shell pode modificar.

Configurações ausentes ao usar a tela

Shells de Login

Se você achar que algumas configurações estão faltando em shells iniciadas por screen , pode ser porque seu shell está configurado apenas para atualizar essas configurações para shells de "login". A maioria dos shells entendem uma convenção especial (em C: **argv == '-' ) que a tela pode ser configurada para usar.

Na documentação tela :

shell command

Set the command to be used to create a new shell. This overrides the value of the environment variable $SHELL. This is useful if you'd like to run a tty-enhancer which is expecting to execute the program speci- fied in $SHELL. If the command begins with a '-' character, the shell will be started as a login-shell.

Para que tela inicie os shells como 'login', inicie tela com screen -s -/bin/bash ou adicione esta linha ao seu .screenrc :

shell -/bin/bash

Ajuste o caminho para qualquer shell que você esteja usando.

tela Configuração

As variáveis de ambiente em falta ou reconfiguradas também podem ser causadas pelos comandos setenv e unsetenv em um arquivo de configuração tela . Você terá que verificar tanto o .screenrc em seu diretório home e o arquivo que sua compilação de tela está usando como o 'system screenrc' (você pode tentar um comando como strings "$(which screen)" | fgrep -i screenrc para encontrar o nome de caminho que foi configurado em tempo de compilação - geralmente é / etc / screenrc para uma tela instalada pelo sistema ; instalações adicionais provavelmente usarão outras nome do caminho). Você pode usar SCREENRC=/dev/null SYSSCREENRC=/dev/null screen para evitar temporariamente esses arquivos de configurações, mas existe uma opção de tempo de compilação que impede o uso efetivo de SYSSCREENRC (presumivelmente para que os administradores do sistema possam forçar um pouco da configuração inicial).

Configurações duplicadas ao usar a tela

É bastante comum adicionar itens a uma variável de ambiente como PATH no (s) arquivo (s) de configuração de um shell para que o valor atualizado esteja disponível para sessões normais do shell (por exemplo xterm ou outras janelas de terminal, sessões de console, etc.). Se tais itens forem adicionados na configuração por shell de um shell (ou, se você estiver usando a configuração -/path/to/shell descrita acima, na configuração shells per-login), então o shell iniciado por screen provavelmente ter várias cópias dos itens adicionados.

Uma estratégia para evitar isso é colocar todas as adições em variáveis como PATH na configuração por-login do seu shell e evitar usar a configuração -/path/to/shell shell com tela .

Outra estratégia é apenas adicionar condicionalmente os novos itens à variável. Dependendo do shell, o código para fazer isso pode ser um pouco complicado, mas geralmente pode ser encapsulado em uma função de shell para facilitar o uso.

Ainda outra estratégia é sempre começar com um valor fixo em seus arquivos de configuração. Isso às vezes pode causar problemas ao mover seus arquivos de configuração de sistema para sistema quando os valores padrão podem variar significativamente.

Diagnóstico

Se você não puder identificar diretamente onde uma modificação específica está acontecendo, tente o seguinte para rastrear onde a alteração está acontecendo.

Verifique o valor atual no seu shell inicial:

echo "$PATH"

Verifique como o próprio shell modifica o valor quando um sub-shell é criado:

/bin/bash -c 'echo "$PATH"'

Verifique como o shell modifica o valor quando um sub-shell de "login" é criado:

perl -e '$s=shift;exec {$s} "-$s", @ARGV or die "unable to start shell"' /bin/bash
echo "$PATH"
exit

Verifique como tela modifica o valor:

printf '#!/bin/sh\nl=/tmp/echo-var.log;rm -f "$l"; echo $PATH >"$l"' >/tmp/echo-var &&
chmod a+x /tmp/echo-var &&
screen -s /tmp/echo-var &&
cat /tmp/echo-var.log
    
por 27.02.2010 / 20:37
2

A última vez que vi um problema semelhante, resolvi-o usando screen -l ao iniciar a tela.

Você pode usar a opção -l ao invocar screen (ativar modo de login on; também controlado pelos comandos deflogin e login em .screenrc ) para definir se a tela deve registrar a janela por padrão (incluindo / removendo a entrada / etc / utmp).

O modo de login está ativado por padrão, mas isso pode ser alterado em tempo de compilação. Se a tela não for compilada com suporte a utmp, esses comandos não estarão disponíveis.

Eu não pareço precisar do modo -l na tela padrão do Debian Lenny (v4.0.3); parece estar ativado por padrão. Meus ~/.profile e ~/.bashrc estão sendo lidos corretamente. Como você está invocando screen ? Qual versão você está usando?

    
por 27.02.2010 / 18:01
2

O problema está no comportamento do launchd no Leopard. Veja este relatório de erros do MacPorts para a tela no Leopard para ver por que ele nunca será consertado, a menos que você possa de alguma forma fazer backport do launchd do Snow Leopard.

link

    
por 22.02.2012 / 11:12
1

Não há nada errado em contratar o seu .bashrc dentro do .bash_profile. Se você estiver usando apenas sua máquina localmente, seu .bash_profile será, na maioria dos casos, fornecido apenas quando você fizer o seu login inicial (obviamente, outras vezes ele será originado).

Organizo meus arquivos para que, se eu quiser que algo seja feito apenas quando eu fizer o login, coloco as informações em .bash_profile e, para todo o resto, coloco-as no .bashrc. PATH é uma coisa que eu coloco no meu .bashrc, e eu uso o .bashrc no meu .bash_profile.

    
por 27.02.2010 / 22:11
0

Sempre que eu tiver algum problema como esse, eu crio um arquivo $HOME/.debug e em todos os arquivos originados / executados durante a chamada de login / shell (por exemplo, ~/.bashrc , ~/.bash_profile , ~/.profile , /etc/bashrc , etc) Tenho como primeira linha

test -f $HOME/.debug && echo $HOME/.bashrc 1>&2

ou similar. Para uma depuração específica, você também pode adicionar coisas como

test -f $HOME/.debug && echo PATH now equals $PATH 1>&2

Dessa forma, você pode ter 100% de certeza absoluta sobre quais arquivos são usados ou não.

O redirecionamento para stderr é importante, você não quer algo bagunçando stdout em muitas situações.

    
por 27.02.2010 / 17:40
0

Você pode ficar com o .profile, já que o sistema não toca no bashrc (como a sessão de gráficos) Agora você simplesmente tem dois conjuntos diferentes de ambiente - um de .profile, outro para bash de .bashrc.

    
por 22.02.2012 / 11:17