Por que o Bash fonte remota .bash_profile em vez de .bashrc

Question

Manual do bash diz:

Bash attempts to determine when it is being run with its standard input connected to a network connection, as when executed by the remote shell daemon, usually rshd, or the secure shell daemon sshd. If Bash determines it is being run in this fashion, it reads and executes commands from ~/.bashrc, if that file exists and is readable.

Essas fontes de Bash ~/.bashrc :

ssh user@host :

Mas essas fontes de Bash ~/.bash_profile :

ssh user@host

Não vejo diferença nesses dois comandos de acordo com a especificação. O stdin não está conectado a uma conexão de rede nos dois casos?

    

Answer 1

Um shell de login lê primeiro /etc/profile e, em seguida, ~/.bash_profile .

Um shell de não-login lê de /etc/bash.bashrc e, em seguida, ~/.bashrc .

Por que isso é importante?

Por causa dessa linha em man ssh :

If command is specified, it is executed on the remote host instead of a login shell.

Em outras palavras, se o comando ssh tiver apenas opções (não um comando), como:

ssh user@host

Ele iniciará um shell de login, um shell de login lê ~/.bash_profile .

Um comando ssh que tem um comando , como:

ssh user@host :

Onde o comando é : (ou não faz nada).
Não irá não iniciar uma shell de login, portanto ~/.bashrc é o que será lido.

stdin remoto

A conexão tty fornecida para / dev / stdin no computador remoto pode ser um tty real ou qualquer outra coisa.

Para:

$ ssh sorontar@localhost
/etc/profile sourced

$ ls -la /dev/stdin
lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0

$ ls -la /proc/self/fd/0
lrwx------ 1 sorontar sorontar 64 Dec 24 19:34 /proc/self/fd/0 -> /dev/pts/3

$ ls -la /dev/pts/3
crw--w---- 1 sorontar tty 136, 3 Dec 24 19:35 /dev/pts/3

Que termina em um TTY (não em uma conexão de rede) quando o bash iniciado o vê.

Para uma conexão ssh com um comando:

$ ssh sorontar@localhost 'ls -la /dev/stdin'
sorontar@localhost's password: 
lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0

A lista de TTYs começa da mesma forma, mas note que o / etc / profile não foi originado.

$ ssh sorontar@localhost 'ls -la /proc/self/fd/0'
sorontar@localhost's password:
lr-x------ 1 sorontar sorontar 64 Dec 24 19:39 /proc/self/fd/0 -> pipe:[6579259]

Que diz ao shell que a conexão é um pipe (não uma conexão de rede).

Assim, em ambos os casos de teste, o shell não pode saber que a conexão é de uma rede e, portanto, não lê ~/.bashrc (se falarmos apenas sobre a conexão a uma rede). Ele lê ~ / .bashrc, mas por um motivo diferente.

    

Answer 2

Você pergunta sobre o "por que" não o "como", então tentarei responder dessa perspectiva. O que se segue será uma boa parte da razão pela qual as coisas aconteceram no passado para resultar em como elas acontecem hoje.

O motivo de ter dois arquivos de inicialização diferentes ("profile" e "rc") é que, no passado, a maneira mais comum de trabalhar em uma máquina era:

1. Faça o login de algum tipo de terminal real ou outra estação de trabalho e obtenha um login shell . Este shell irá invocar /etc/profile e ~/.profile e configurar o ambiente para o usuário.

2. Invoque o ambiente que o usuário deseja inserir. Este ambiente pode ser o Xorg, mas na maioria dos casos foi um multiplexador como o GNU screen.

3. O ambiente (por exemplo, a tela GNU) invocaria shells extras (sem login) que herdam o ambiente do shell de login pai.

Essa era a maneira comum de efetuar login em uma máquina UNIX durante o tempo em que csh e bash estavam sendo desenvolvidos. Portanto, foi considerado um desperdício ler novamente ~/.profile nos shells que estavam herdando o ambiente de qualquer maneira.

bash , em seguida, adicionou ~/.bashrc para configuração extra para esses shells que não são de login. csh (e tcsh ) nunca adicionou nenhum tipo de arquivo "rc" para shells que não são de login. Note que csh / tcsh não são shells compatíveis com o shell bourne (que faz parte do POSIX) enquanto bash é. Outro shell compatível com bourne, ksh , incluiu uma variável de ambiente (chamada ENV ), que, se foi definida, seria usada como um arquivo de comandos de execução ("rc") para não-login ksh .

Então, sim, novas versões de bourne shells adicionaram o arquivo de configuração extra como uma conveniência para aliases e outras opções rápidas que estariam presentes dentro dos shells interceptados pela tela GNU (ou similar), mas não presentes no shell que você obtém quando primeiro entre na máquina.

Com o aumento dos gerenciadores de exibição gráfica (GDMs), a diferenciação entre os arquivos "profile" e "rc" tornou-se insignificante porque o GDM teria seus próprios arquivos de inicialização (por exemplo, ~/.xinit e ~/.xsession ). Então, shells declarados de dentro do GDM podem ser shells de login ou não-login dependendo dos caprichos do usuário, e o caso em que um shell que não seja de login sempre teria um pai que é um shell de login não é mais verdadeiro.

Extra

Uma das minhas tabelas favoritas sobre a comparação de arquivos de inicialização do shell mostra como os shells compatíveis com shell da bourne usam o profile arquivos enquanto outras não. Isso porque, no passado, o shell inicial (aquele que iniciava o muxer) precisava ser um shell compatível com o bourne.