it-swarm.com.de

Warum wird die Remote-Bash-Quelle .bash_profile anstelle von .bashrc verwendet?

Bash Manual sagt:

Bash versucht festzustellen, wann es ausgeführt wird, wenn seine Standardeingabe mit einer Netzwerkverbindung verbunden ist, wie dies vom Remote-Shell-Daemon, normalerweise rshd, oder vom sicheren Shell-Daemon sshd ausgeführt wird. Wenn Bash feststellt, dass es auf diese Weise ausgeführt wird, liest es Befehle von ~/.bashrc und führt sie aus, sofern diese Datei vorhanden und lesbar ist.

Diese Bash-Quellen ~/.bashrc:

ssh [email protected] :

Aber diese Bash-Quellen ~/.bash_profile:

ssh [email protected]

Ich sehe keinen Unterschied in diesen beiden Befehlen gemäß der Spezifikation. Ist stdin nicht in beiden Fällen mit einer Netzwerkverbindung verbunden?

29
Cyker

Eine Login-Shell liest zuerst /etc/profile Und dann ~/.bash_profile.

Eine nicht angemeldete Shell liest aus /etc/bash.bashrc Und dann aus ~/.bashrc.

Warum ist das wichtig?

Wegen dieser Zeile in man ssh:

Wenn der Befehl angegeben wird, wird er auf dem Remote-Host anstelle einer Anmeldeshell ausgeführt.

Mit anderen Worten, wenn der Befehl ssh nur Optionen enthält (kein Befehl), wie z.

ssh [email protected]

Es wird eine Login-Shell gestartet, eine Login-Shell liest ~/.bash_profile.

Ein ssh-Befehl, der einen Befehl hat, wie:

ssh [email protected] :

Wo der Befehl : Ist (oder nichts tun).
Es wird nicht eine Login-Shell starten, daher wird ~/.bashrc Gelesen.


Remote stdin

Die mitgelieferte tty-Verbindung für/dev/stdin auf dem Remotecomputer kann eine tatsächliche tty oder etwas anderes sein.

Zum:

$ ssh [email protected]
/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

Was in einem TTY (keine Netzwerkverbindung) endet, wie es die gestartete Bash sieht.

Für eine SSH-Verbindung mit einem Befehl:

$ ssh [email protected] 'ls -la /dev/stdin'
[email protected]'s password: 
lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0

Die Liste der TTYs beginnt gleich, aber beachten Sie, dass/etc/profile nicht bezogen wurde.

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

Dies teilt der Shell mit, dass die Verbindung eine Pipe ist (keine Netzwerkverbindung).

In beiden Testfällen kann die Shell also nicht erkennen, dass die Verbindung von einem Netzwerk stammt, und liest daher nicht ~/.bashrc (Wenn wir nur über die Verbindung zu einem Netzwerk sprechen). Es liest ~/.bashrc, aber aus einem anderen Grund.

51
Isaac

Sie fragen nach dem "Warum" und nicht nach dem "Wie", also werde ich versuchen, aus dieser Perspektive zu antworten. Das Folgende wird eine gute Begründung dafür sein, warum Dinge in der Vergangenheit passiert sind, um zu dem zu führen, wie sie heute geschehen.


Der Grund für zwei verschiedene Startdateien ("Profil" und "RC") ist, dass in der Vergangenheit die übliche Arbeitsweise auf einem Computer war:

  1. Melden Sie sich von einem echten Terminal oder einer anderen Workstation aus an und erhalten Sie eine Login-Shell . Diese Shell ruft /etc/profile und ~/.profile und richten Sie die Umgebung für den Benutzer ein.

  2. Rufen Sie die Umgebung auf, in die der Benutzer eintreten möchte. Diese Umgebung könnte Xorg sein, aber in den meisten Fällen war es ein Multiplexer wie GNU screen).

  3. Die Umgebung (z. B. GNU)) würde dann zusätzliche Shells (ohne Anmeldung) aufrufen, die die Umgebung von der übergeordneten Anmeldeshell erben.

Dies war die übliche Methode, sich während der Entwicklung von csh und bash bei einem UNIX-Computer anzumelden. Daher wurde es als verschwenderisch angesehen, ~/.profile wieder in den Shells, die die Umgebung sowieso geerbt haben.

bash dann hinzugefügt ~/.bashrc für zusätzliche Konfiguration für diese Nicht-Login-Shells. csh (und tcsh) haben niemals eine "rc" -Datei für Nicht-Login-Shells hinzugefügt. Beachten Sie, dass csh/tcsh keine Shells sind, die mit der bourne Shell (die Teil von POSIX ist) kompatibel sind, während bash ist. Eine andere bourne-kompatible Shell, ksh, fügte eine Umgebungsvariable (ENV genannt) hinzu, die, falls definiert, als Ausführungsbefehlsdatei ("rc") für die Nichtanmeldung verwendet wird ksh.

Also ja, neuere Versionen von Bourne-Shells haben die zusätzliche Konfigurationsdatei hinzugefügt, um Aliase und andere schnelle Optionen zu vereinfachen, die in den Shells vorhanden sind, die durch GNU Bildschirm (oder ähnlich), aber nicht in vorhanden sind) die Shell, die Sie erhalten, wenn Sie die Maschine zum ersten Mal betreten.

Mit der Einführung von GDMs (Graphical Display Manager) wurde die Unterscheidung zwischen "Profil" -Dateien und "RC" -Dateien bedeutungslos, da das GDM über eigene Initialisierungsdateien verfügen würde (z. B. ~/.xinit und ~/.xsession). Dann können Shells, die innerhalb des GDM angegeben werden, abhängig von den Launen eines Benutzers Login- oder Nicht-Login-Shells sein, und der Fall, in dem eine Nicht-Login-Shell immer ein übergeordnetes Element hat, das eine Login-Shell ist, ist nicht mehr wahr.

Extra

Eine meiner Lieblingstabellen zum Vergleich der Shell-Startdateien zeigt, wie bourne Shell-kompatible Shells die profile -Dateien verwenden, während andere Shells dies nicht tun. Dies liegt daran, dass in der Vergangenheit die ursprüngliche Shell (die den Muxer gestartet hat) eine bourne-kompatible Shell sein musste.

12
grochmal