Por que a fonte padrão ~ / .profile do Ubuntu ~ / .bashrc?

Question

Estes são os conteúdos do estoque ~/.profile que veio com meu 13.10 (linhas comentadas removidas):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Isto é herdado do Debian, mas por que a Canonical decidiu mantê-lo? Tanto quanto eu sei, não é a maneira padrão * nix e eu vi vários sistemas onde isso não aconteceu, então eu suponho que eles devem ter tido um bom motivo para isso. Isso pode causar um comportamento inesperado ao executar shells de login (como, por exemplo, ao inserir na máquina) em que o usuário não esperaria ter ~/.bashrc sourced.

O único benefício que posso imaginar é não confundir o usuário com muitos arquivos de inicialização e permitir que eles editem .bashrc sozinhos e tenham essa leitura independentemente do tipo de shell. Isso, no entanto, é um benefício duvidoso, já que muitas vezes é útil ter configurações diferentes para login e para shells interativos e isso impede você de fazer isso. Além disso, os shells de login muitas vezes não são executados em um ambiente gráfico e isso pode causar erros, avisos e problemas (oh my!) Dependendo do que você definiu nesses arquivos.

Então, por que o Ubuntu faz isso, o que me falta?

    

Answer 1

Esta é uma decisão do upstream vinda do Debian. A justificativa para isso é explicada nesta muito interessante post wiki , da qual o seguinte é um trecho. O resumo executivo é "para garantir que os logins GUI e não GUI funcionem da mesma maneira":

  

Vamos pegar o xdm como um exemplo. Pierre um dia volta de férias e descobre que o administrador do sistema instalou o xdm no sistema Debian. Ele loga bem, e o xdm lê seu arquivo .xsession e roda o fluxbox. Tudo parece estar bem até que ele receba uma mensagem de erro no local errado! Como ele substitui a variável LANG em seu .bash_profile, e como o xdm nunca lê .bash_profile, sua variável LANG agora está definida como en_US em vez de fr_CA.

     

Agora, a solução ingênua para esse problema é que, em vez de iniciar o "xterm", ele poderia configurar seu gerenciador de janelas para iniciar o "xterm -ls". Esse sinalizador diz ao xterm que, em vez de lançar um shell normal, ele deve iniciar um shell de login. Sob esta configuração, o xterm gera / bin / bash mas coloca "- / bin / bash" (ou talvez "-bash") no vetor argumento, então o bash age como um shell de login. Isso significa que toda vez que ele abrir um novo xterm, ele lerá / etc / profile e .bash_profile (comportamento bash integrado) e, em seguida, .bashrc (porque .bash_profile diz para fazer isso). Isso pode parecer funcionar bem no início - seus arquivos de pontos não são pesados, então ele nem percebe o atraso - mas há um problema mais sutil. Ele também lança um navegador da Web diretamente de seu menu do fluxbox, e o navegador da web herda a variável LANG do fluxbox, que agora está configurada para o local errado. Então, enquanto seus xterms podem estar bem, e qualquer coisa lançada a partir de seus xterms pode estar bem, seu navegador ainda está lhe dando páginas no local errado.

     

Então, qual é a melhor solução para esse problema? Não há realmente um universal. Uma abordagem melhor é modificar o arquivo .xsession para algo parecido com isto:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

     

Isso faz com que o shell que interpreta o script .xsession leia em / etc / profile e .bash_profile, se existirem e forem legíveis, antes de executar xmodmap ou xterm ou "executar" o gerenciador de janelas. No entanto, há uma possível desvantagem dessa abordagem: sob o xdm, o shell que lê o .xsession é executado sem um terminal de controle. Se / etc / profile ou .bash_profile usarem qualquer comando que assuma a presença de um terminal (como "fortune" ou "stty"), esses comandos podem falhar. Esta é a principal razão pela qual o xdm não lê esses arquivos por padrão. Se você for usar essa abordagem, deve certificar-se de que todos os comandos em seus "arquivos de ponto" sejam seguros para serem executados quando não houver terminal.

    

Answer 2

Este é o comportamento padrão do Ubuntu, ~/.bashrc é o arquivo de inicialização por shell interativo por nível de usuário. Quando você abre um terminal, basicamente, você inicia um non-login, shell interativo que lê ~/.bashrc e conteúdo de ~/.bashrc é originado e exportado para o seu ambiente shell atual. Isso ajuda a obter todas as variáveis de shell definidas pelo usuário e funções no shell atual. Além disso, você pode encontrar linhas como esta

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

para obter aliases definidos pelo usuário no ambiente shell atual.

Isso é importante para fornecer uma boa experiência ao usuário também. Por exemplo, pode-se armazenar credenciais de proxy em .bashrc , a menos que seja originado nenhum dos aplicativos de terminal ( viz , ping , wget , curl , lynx etc.) funcionará devidamente. Ou você precisa fornecer as credenciais de proxy sempre que abrir um terminal.

Além do padrão do Ubuntu .bashrc contém muitos apelidos amigáveis ao usuário (para ls e grep para imprimir saída colorida), muitas novas definições para diferentes variáveis de shell que aumentam a experiência do usuário.

Mas no caso do seu login ssh , ou login no console virtual , você basicamente obtém um shell de login interativo. Lá, o arquivo de iniciação do shell é ~/.profile . Portanto, a menos que você escolha ~/.bashrc , você perderá todas as configurações úteis em .bashrc . É por isso que o padrão do Ubuntu ~/.profile source ~/.bashrc

Caso a evitar

• você nunca deve pesquisar ~/.profile form dentro de ~/.bashrc ao mesmo tempo em que ~/.bashrc está sendo originado de ~/.profile . Ele criará um loop infinito de situação e, como resultado, seu terminal será suspenso, a menos que você pressione Ctrl + C . Em tal situação, se você colocar uma linha no seu ~/.bashrc

set -x

Então você pode ver que o descritor de arquivo está parando quando você abre um terminal.