Linux/Umgebung/Variable

Linux/Umgebungsvariablen - Kurzbeschreibung

Beschreibung

Umgebungsvariablen (environ(7)) sind benannte Zeichenketten, die für alle Anwendungen verfügbar sind. Variablen werden verwendet, um das Verhalten jeder Anwendung an die Umgebung, in der sie läuft, anzupassen. Sie können Pfade für Dateien, Sprachoptionen und so weiter definieren. Sie können im Handbuch jeder Anwendung nachlesen, welche Variablen von dieser Anwendung verwendet werden

Es gibt jedoch einige Standardvariablen in Linux-Umgebungen

* PATH = Durch Doppelpunkt getrennte Liste von Verzeichnissen, in denen nach Befehlen gesucht wird
* HOME = Das Heimatverzeichnis des aktuellen Benutzers
* LOGNAME = Der Name des aktuellen Benutzers
* SHELL = Die bevorzugte Shell des Benutzers
* EDITOR = Der bevorzugte Texteditor des Benutzers
* MAIL = Der Ort des elektronischen Posteingangs des Benutzers

Um Ihre aktuell definierten Variablen zu sehen, öffnen Sie Ihr Terminal und geben Sie den Befehl `env` ein

Variablen werden mit Name-Wert-Paaren definiert: `NAME=beliebige Zeichenkette als Wert`. Der Variablenname wird normalerweise in Großbuchstaben geschrieben. Alles, was auf das Gleichheitszeichen folgt, gilt als Wert der Variable bis zum abschließenden Zeilenvorschubzeichen. Variablen können ad hoc in einem Terminal definiert werden, indem man den entsprechenden Befehl schreibt. In Bash wäre dies `export MYVAL="Hello world"`. In diesem Fall bleibt die Variable bis zum Ende der Terminalsitzung definiert

Wenn Sie etwas an eine Variable anhängen wollen, anstatt den vorherigen Wert zu überschreiben, fügen Sie den Variablennamen in die neue Definition ein. Z.B. in der Bash: `export PATH=$PATH:~/bin`. Dieses Beispiel zeigt, wie man das Verzeichnis bin im Heimatverzeichnis des Benutzers an die Umgebungsvariable PATH anhängt

In den meisten Fällen ist es am praktischsten, diese Variablen in einer Konfigurationsdatei zu speichern, die beim Systemstart und bei der Benutzeranmeldung gelesen wird, so dass sie automatisch verfügbar sind. Leider ist dies nicht immer so einfach, wie es klingt. Und warum? Dafür gibt es mehrere Gründe

1. Die meisten Programme lesen keine Konfigurationsdatei, um ihre Umgebung einzustellen; stattdessen erben sie diese von einem übergeordneten Prozess. Sie müssen die Einstellungen des Elternprozesses so konfigurieren, dass er sie an alle seine Kinder weitergibt
1. Verschiedene Shells und Fenstermanager sind oft die Elternprogramme, nach denen wir suchen, aber jedes von ihnen liest eine andere Konfigurationsdatei (Dot-Datei), wenn es startet
1. Einige Desktop-Umgebungen starten Programme über einen Hilfsdienst, so dass der Fenstermanager möglicherweise nicht das gesuchte übergeordnete Programm ist

Mit diesem Wissen wissen wir nun, dass wir sowohl die Startreihenfolge der Systemprozesse als auch die Konfigurationsdateien, die sie beim Start lesen, berücksichtigen müssen. Siehe die Seite DotFiles, oder lesen Sie weiter

Legen wir los! Es gibt mehrere Möglichkeiten, auf Ihren Linux-Rechner zuzugreifen: über eine Textkonsole, über eine grafische Anmeldung (Display Manager) oder über Remote-SH

Anwendung

Textkonsole

Textkonsole oder entfernte ssh verwenden

Sowohl die Anmeldung über die Textkonsole als auch die Fernanmeldung über ssh enden mit einer Login-Shell. Die Variablen werden schrittweise von mehreren Prozessen nacheinander erworben. Jeder Prozess fügt einige weitere Variablen hinzu

1. Am Ende des Bootvorgangs wird die Mutter aller Prozesse init gestartet. Die Umgebung von init, einschließlich PATH, ist in seinem Quellcode definiert und kann zur Laufzeit nicht geändert werden
1. init führt die Startskripte aus /lib/systemd/system (unter systemd) oder /etc/rc?.d aus, basierend auf dem in /etc/inittab (unter sysvinit) eingestellten Runlevel. Jeder Dienst oder jedes Skript definiert seine eigenen benötigten Umgebungsvariablen. Unter systemd werden Variablen, die in verschiedenen environment.d-Verzeichnissen definiert sind, den systemd-Benutzereinheiten zur Verfügung gestellt; siehe die environment.d(5)-Manualseite für Details
1. Am Ende des Bootens führt init einen getty-Prozess auf einer oder mehreren virtuellen Konsolen aus. getty wartet darauf, dass der Benutzer seinen Namen eingibt, setzt dann die Variable TERM und führt login aus, um nach einem Passwort zu fragen
1. login überprüft /etc/passwd und /etc/shadow auf die Kontodaten des Benutzers. Wenn das Passwort akzeptabel ist, setzt login HOME, SHELL, PATH, LOGNAME und MAIL basierend auf dem Inhalt von /etc/passwd, überprüft PAM und führt schließlich die Login-Shell des Benutzers aus
a. PAM kann login anweisen, auch die Variablen in /etc/environment zu lesen. Dies ist die Voreinstellung
1. Die Login-Shell startet und liest ihre shellspezifischen Konfigurationsdateien
a. DebianPkg:bash liest zuerst /etc/profile, um Werte zu erhalten, die für alle Benutzer definiert sind. Nachdem sie diese Datei gelesen hat, sucht sie nach ~/.bash_profile, ~/.bash_login und ~/.profile, in dieser Reihenfolge, und liest und führt Befehle aus der ersten dieser Dateien, die existiert und lesbar ist, aus. Siehe DotFiles für weitere Details
a. (bitte geben Sie auch andere Shells an)

Für ssh-Anmeldungen ist die Kette ähnlich. Das init-System führt den sshd-Dienst aus, der auf entfernte Client-Verbindungen wartet

1. sshd hat eine Startumgebung, die durch seine Servicedatei definiert ist
1. PAM kann zusätzliche Variablen bereitstellen
1. /etc/ssh/sshd_config definiert zusätzliche Umgebungsvariablen, die vom Client akzeptiert werden können
1. Nach der Authentifizierung führt sshd eine Login-Shell aus, die ihre shellspezifischen Dot-Dateien wie oben angegeben liest

Nun sind die Umgebungsvariablen bereit, von den Anwendungen verwendet zu werden, die Sie von der Shell aus starten

Grafischen Anmeldung

Verwendung eines grafischen Anzeigemanagers

Der Anmeldevorgang ist unter einem DisplayManager ganz anders

1. Am Ende des Bootens wird die Mutter aller Prozesse -- init -- gestartet
1. init führt Dienste wie oben beschrieben aus. Einer dieser Dienste wird Ihr DisplayManager sein
1. Wenn sich der Benutzer erfolgreich anmeldet, prüft der Display-Manager PAM und startet dann eine Xsession
a. PAM kann den DM anweisen, die Variablen aus /etc/environment zu lesen
1. Die Xsession liest ~/.xsessionrc und möglicherweise andere Dateien, abhängig vom Sitzungstyp

Ob die Startdateien der Shell (/etc/profile und ~/.profile und so weiter) bei grafischen Anmeldungen eine Wirkung haben, hängt vom DisplayManager ab. Zum Beispiel lädt SDDM sie standardmäßig, während sie von LightDM in der Debian-Konfiguration ignoriert werden. Ein Benutzer kann eine ~/.xsessionrc-Datei erstellen, die diese Dateien liest

Desktop-Umgebungen und systemd-Benutzerdienste

Einige Desktop-Umgebungen starten Programme über systemd-Benutzerdienste. Diese Programme erben ihre Umgebung nicht von der X-Sitzung. Um die Umgebung für solche Programme zu konfigurieren, muss man den Daemon systemd --user konfigurieren

Dies kann wie folgt geschehen

* mkdir -p ~/.config/systemd/user/service.d
* Verwenden Sie Ihren bevorzugten Texteditor, um eine Datei in diesem Verzeichnis zu erstellen. Der Dateiname muss mit .conf enden, sonst wird er nicht erkannt. Nehmen wir an, Sie verwenden env.conf als Dateinamen. Fügen Sie innerhalb der Datei env.conf die folgenden Zeilen ein
. {{{

[Service] Umgebung="MYVAR=irgendein Wert" }}}

* Für eine Liste von Escape-Sequenzen, die in dieser Datei verwendet werden können, siehe systemd.unit(5)
* systemctl --user daemon-reload
* In einigen Desktop-Umgebungen müssen Sie möglicherweise auch einen Start- oder Menüdienst neu starten oder sich ab- und wieder anmelden

Sie können mehr als eine Umgebungsvariable angeben, und Sie können hier auch umask oder Ressourcenlimits konfigurieren (siehe Standardumask setzen für Details). Sie können mehrere Dateien haben, oder eine Datei mit mehreren Einträgen, wie Sie es für richtig halten

environment.d(5) bietet eine weitere Möglichkeit, dies zu erreichen, aber sie ist strikt auf Umgebungsvariablen beschränkt (keine umask oder Ressourcenbeschränkungen) und verwendet eine andere Syntax. Es unterstützt auch nicht die Spezifizierer (%h, etc.), die systemd.unit(5) definiert, sondern hat stattdessen eine Pseudo-Shellvariablen-Expansionssyntax

Kurzanleitung

Für die Eiligen, die das System einfach nur zum Laufen bringen müssen, können Sie folgendes tun

* Legen Sie alle globalen Umgebungsvariablen, d.h. diejenigen, die alle Benutzer betreffen, in /etc/environment ab
* Denken Sie daran, dass diese Datei von PAM gelesen wird, nicht von einer Shell. Sie können hier keine Shell-Erweiterungen verwenden. Z.B. MAIL=$HOME/Maildir/ wird nicht funktionieren!
* Es gibt keine shell-agnostische und login-unabhängige Lösung für das Problem, wie man die Umgebung für alle Benutzer konfiguriert, abgesehen von den trivialen Fällen, die PAM handhaben kann
* Legen Sie alle Ihre vorübergehenden Shell-Einstellungen (Aliase, Funktionen, Shell-Optionen) in ~/.bashrc ab
* Legen Sie alle Ihre Umgebungsvariablen in ~/.profile ab
* Erstellen oder bearbeiten Sie die Datei ~/.bash_profile und fügen Sie Befehle ein
{{{
if [ -f ~/.profile ]; then
. ~/.profile
fi
}}}
* Erstellen oder bearbeiten Sie die Datei ~/.xsessionrc und fügen Sie die gleichen Befehle wie oben ein
* Wenn Sie eine Desktop-Umgebung verwenden, erstellen Sie eine Datei env.conf, wie im vorherigen Abschnitt gezeigt

Dies ist ein schneller und schmutziger Ansatz! Nicht für den pedantischen Benutzer

Hinweise und Ausnahmen

SysV, Systemd und init

Laut GW in [PATH revisited: one PATH to rule the [Debian World"]] ist /sbin/init das, was vom Kernel ausgeführt wird, unabhängig davon, welches Init-System installiert ist

{{{
$ ps -fp 1
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Okt07 ? 00:01:58 /sbin/init

$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Sep 20 08:15 /sbin/init -> /lib/systemd/systemd*
}}}

startx vom Terminal aus starten

Wenn Sie X Window (die grafische Benutzeroberfläche) von einer Textkonsole aus starten, sind Ihre Umgebungsvariablen bereits von Ihrer Login-Shell definiert, wie oben erläutert. Allerdings kann es sein, dass der Window-Manager dieselben Dateien erneut einliest (siehe unten). Dies ist normalerweise kein Problem, aber Sie können unerwartete Ergebnisse erhalten, wie z.B. dass alle Einträge in PATH doppelt aufgeführt sind

Shell-Kaskadierung

Wenn Sie innerhalb der Login-Shell eine weitere Shell starten (ja, das ist möglich), ist die zweite Shell eine Nicht-Login-Shell. Sie liest keine benannten Startdateien, sondern sucht stattdessen das Nicht-Login-Startskript aus dem Home-Verzeichnis des Benutzers. Bei der Bash heißt es ~/.bashrc. Um zu vermeiden, dass dieselben Werte an zwei Stellen angegeben werden, schließt das Startskript der Login-Shell ~/.bash_profile am Ende seiner Ausführung die ~/.bashrc ein. Zur Implementierung fügen Sie folgendes in Ihr ~/.bash_profile ein

{{{
if [ -f ~/.bashrc ]; then
. ~/.bashrc;
fi
}}}

Terminal-Fenster in X

Wenn Sie ein Terminal-/Konsolenfenster in einer grafischen Desktop-Umgebung starten, ist es ein Nicht-Login-Terminal und liest nur das Nicht-Login-Startskript des Benutzers. Für Bash ist dies ~/.bashrc

Verwendung von su

Der Befehl su wird verwendet, um während einer Login-Sitzung ein anderer Benutzer zu werden. Er wird üblicherweise verwendet, um vorübergehend Root-Rechte von einer normalen Sitzung zu erhalten. In Stretch und früheren Versionen setzt der su-Befehl Ihren PATH-Umgebungswert auf einen Wert zurück, der in /etc/login.defs durch die Variablen ENV_PATH und ENV_SUPATH definiert ist. In Buster und späteren Versionen ändert su Ihre PATH-Variable standardmäßig nicht (für Details, siehe /usr/share/doc/util-linux/NEWS.Debian.gz). Sie können es anweisen, dies zu tun, indem Sie die Datei /etc/default/su erstellen und die Zeile ALWAYS_SET_PATH yes darin einfügen

Bitte beachten Sie, dass der Gnome-Helfer gksu aus dem Gnome-Panel standardmäßig su intern verwendet (d.h. Sie könnten Ihren PATH "verlieren", wenn Sie ihn nicht in login.defs in stretch konfigurieren)

. Bedeutet das, dass gksu in buster aufgrund des fehlenden /sbin u.a. im PATH schlichtweg versagt?

Anhang

Siehe auch

• Linux/Umgebung/Variable