Frage Warum muss ich ".profile" in jedem Terminal, das ich öffne, "quellen"?


Wenn wir eine Variable in ändern ~/.profile in Ubuntu, dann führen wir den Befehl aus source .profile. Dann ist die Änderung wirksam nur in diesem Terminal. Wenn wir ein neues Terminal öffnen, müssen wir den Befehl ausführen source .profile nochmal. Es scheint also, dass verschiedene Terminals ihre eigene Umgebung haben, obwohl sie zu demselben Benutzer gehören können.

Welchen Vorteil hat es, wenn jedes Terminal seinen eigenen Umgebungspfad hat? Es scheint, dass es besser wäre, wenn verschiedene Endgeräte, die zu demselben Benutzer gehören, dieselbe Umgebungsvariable teilen.


6
2018-01-07 08:47


Ursprung


Mögliches Duplikat von Wie setze ich Umgebungsvariablen? - galoget
Wenn Ihre Login- "Shell" eine GUI ist, hilft es wenig, die Variable in das Login-Skript von sh anstatt in die GUI zu setzen. - ikegami


Antworten:


Der Grund dafür ist, dass ~/.profile wird nur von Login-Shells bezogen. Wenn Sie ein neues Terminalfenster öffnen, ist die startende Shell standardmäßig eine Nicht-Login-Shell. Wenn Sie sich abmelden und erneut anmelden, wird die Änderung in ~/.profile wird in allen Ihren Terminals wirksam sein, weil ~/.profile wird abgerufen, wenn Sie sich bei Ihrer Sitzung anmelden.

Es ist nicht so, dass verschiedene Terminalfenster eine andere Umgebung haben, als dieses Sourcing ~/.profile führt nur aus ~/.profile in der aktuellen Shell (genau das ist das source Befehl tut).

Im Gegensatz dazu eine Änderung an ~/.bashrc wirkt sich sofort auf jedes neue Terminalfenster aus, das Sie öffnen, oder auf jede Bash-Shell, die Sie durch Eingabe starten bash, weil es von allen interaktiven Bash-Shells stammt.


14
2018-01-07 09:14





Umgebungsvariablen sind nicht nur für Benutzerpräferenzen. Sie sind ein allgemeiner Mechanismus zum Übermitteln einer Vielzahl von Einstellungsinformationen von einem übergeordneten Prozess an untergeordnete Prozesse, die gestartet werden.

Es gibt zahlreiche Fälle, in denen ein Prozess bestimmte Umgebungsvariablen zur Beeinflussung setzt gerade Prozesse beginnt es. Beispielsweise kann ein Skript die Gebietsschemaeinstellungen für von ihm gestartete Befehle absichtlich zurücksetzen, so dass es die Ausgabe von ihnen analysieren kann. Die Buildskripts für viele große Softwarepakete verwenden verschachtelte Aufrufe von make die über Umgebungsvariablen miteinander koordinieren. Spezialisierte Tools müssen möglicherweise die Arbeitsbedingungen anderer Programme ändern, die sie starten, indem sie Tricks mit $ LD_PRELOAD oder $ PATH ausführen.

Wenn etwas, das ein Benutzer in einem anderen Fenster macht, während eine lange Übersetzung in einem anderen läuft, würde die Umgebungsvariablen von alle Seine Prozesse hinter seinem Rücken, Wahnsinn und Chaos würden folgen.

Andere Umgebungsvariablen enthalten Informationen über die bestimmte Sitzung, in der ein Prozess gestartet wird. Programme erwarten, dass $ TERM den Befehlssatz des bestimmten Terminals (oder Terminalemulators) beschreibt, mit dem sie verbunden sind. Eine allgemeine Benutzereinstellung zu machen, würde es unmöglich machen, mit mehreren verschiedenen Arten von Endgeräten im selben System angemeldet zu sein. Selbst wenn Sie nur ein Stück Terminal-Hardware haben und sich nie remote anmelden, werden Programme wie screen hängen davon ab, einen anderen $ TERM für die Prozesse festzulegen, die in ihrer Sitzung ausgeführt werden.

Eine bessere Frage wäre, warum wir einen Prozess-zu-Subprozess-Kommunikationsmechanismus für Benutzereinstellungen statt einer Benutzerdatenbank verwenden.

Antwort: Weil es funktioniert gut genug und die Vorteile der Erstellung einer Datenbank pro Benutzer sind nicht groß genug, um die Arbeit zu ändern alles benutzen Das anstelle von Umgebungsvariablen würde getan werden.

(Ich kann mir dort sehr wenige Einstellungen vorstellen würde nicht Es gibt einige Anwendungsfälle, in denen es praktisch ist, sie nur für die Ausführung eines einzelnen Skripts zu ändern. Um also nicht die Funktionalität zu verlieren, müsste alles noch sein übersteuerbar durch Umgebungsvariablen, was zu zusätzlicher Komplexität und verwirrteren Benutzern führt).

Alternativen sind es nicht existieren. Zum Beispiel sind X-Ressourcen pro Anzeigesitzung und nicht pro Prozess. Sie sind jedoch für Befehlszeilenprogramme schwer zugänglich. Befehlszeilenprogramme müssen normalerweise für Remote-Logins funktionieren, die nicht gerade funktionieren haben ein X-Server zum Herstellen einer Verbindung.


3
2018-01-07 16:06