Perché Bash remoto genera .bash_profile invece di .bashrc

Bash Manual dice:

Bash tenta di determinare quando viene eseguito con il suo input standard collegato a una connessione di rete, come quando viene eseguito dal daemon di shell remoto, di solito rshd, o dal daemon di shell sicuro sshd. Se Bash determina che viene eseguito in questo modo, legge ed esegue i comandi da ~ / .bashrc, se quel file esiste ed è leggibile.

Questo Bash fonti ~/.bashrc:

ssh user@host :

Ma questa fonte di Bash ~/.bash_profile:

ssh user@host

Non vedo alcuna differenza in questi due comandi secondo le specifiche. Lo stdin non è collegato a una connessione di rete in entrambi i casi?

Una shell di login legge prima /etc/profilee poi ~/.bash_profile.

Una shell senza login legge da /etc/bash.bashrce poi ~/.bashrc.

Perché è importante?

A causa di questa linea in man ssh:

Se viene specificato un comando , viene eseguito sull'host remoto anziché su una shell di accesso.

In altre parole, se il comando ssh ha solo opzioni (non un comando), come:

ssh user@host

Avvierà una shell di login, una shell di login legge ~/.bash_profile.

Un comando ssh che ha un comando , come:

ssh user@host :

Dove si trova il comando :(o non fare nulla).
Sarà Non avviare una shell di login, quindi, ~/.bashrcè quello che verrà letto.

Stdin remoto

La connessione tty fornita per / dev / stdin nel computer remoto può essere una tty effettiva o qualcos'altro.

Per:

$ 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

Il che termina in un TTY (non una connessione di rete) come viene visto dalla bash avviata.

Per una connessione ssh con un 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

L'elenco dei TTY inizia allo stesso modo, ma nota che / etc / profile non è stato fornito.

$ 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]

Il che dice alla shell che la connessione è una pipe (non una connessione di rete).

Quindi, in entrambi i casi di test, la shell non è in grado di sapere che la connessione proviene da una rete e quindi non legge ~/.bashrc(se parliamo solo della connessione a una rete). Legge ~ / .bashrc, ma per una ragione diversa.

Ti chiedi del "perché", non del "come", quindi proverò a rispondere da quella prospettiva. Quanto segue sarà una buona parte della logica del motivo per cui le cose sono successe in passato per determinare come accadono oggi.

Il motivo per avere due diversi file di avvio ("profilo" e "rc") è che in passato il modo comune di lavorare su una macchina era:

1. Accedi da una sorta di terminale reale o altra workstation e ottieni una shell di login . Questa shell invocherà /etc/profilee ~/.profileconfigurerà l'ambiente per l'utente.

2. Richiama l'ambiente in cui l'utente vuole entrare. Questo ambiente potrebbe essere Xorg, ma nella maggior parte dei casi era un multiplexer come lo schermo GNU.

3. L'ambiente (ad esempio la schermata GNU) invocherebbe quindi shell extra (non di accesso) che ereditano l'ambiente dalla shell di accesso principale.

Questo era il modo comune di accedere a una macchina UNIX durante il periodo in cui cshe in bashfase di sviluppo. Pertanto si è ritenuto uno spreco di leggere ~/.profiledi nuovo nei gusci che sono stati ereditano l'ambiente in ogni caso.

bashquindi aggiunto ~/.bashrcper una configurazione aggiuntiva per queste shell non di accesso. csh(e tcsh) non ha mai aggiunto alcun tipo di file "rc" per shell non di accesso. Nota che csh/ tcshnon sono shell compatibili con la shell bourne (che fa parte di POSIX) mentre lo bashè. Un'altra shell compatibile bourne ksh, ha aggiunto una variabile di ambiente (chiamata ENV), che, se definita, sarebbe utilizzata come file di comandi di esecuzione ("rc") per il non accesso ksh.

Quindi sì, le versioni più recenti delle shell bourne hanno aggiunto il file di configurazione aggiuntivo come una comodità per gli alias e altre opzioni rapide che sarebbero presenti all'interno delle shell mescolate dallo schermo GNU (o simili) ma non presenti nella shell che si ottiene quando si accede per la prima volta al macchina.

Con l'aumento dei gestori di display grafici (GDM) la differenziazione tra i file "profilo" e "rc" è diventata insignificante perché GDM avrebbe i suoi file di inizializzazione (ad es. ~/.xinitE ~/.xsession). Quindi, le shell dichiarate dall'interno di GDM potrebbero essere shell di login o non login a seconda dei capricci di un utente, e il caso in cui una shell non login avrebbe sempre un genitore che è una shell di login non è più vero.

Extra

Una delle mie tabelle preferite sul confronto dei file di avvio della shell mostra come le shell compatibili con bourne shell utilizzano i profilefile mentre altre shell non lo fanno. Questo perché in passato la shell iniziale (quella che ha avviato il muxer) doveva essere una shell compatibile bourne.