Linux/Umgebung/Variable

topic - 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.

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.

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

Dokumentation

RFC

RFC	Titel
0000