Linux/Umgebung/Variable

Linux/Umgebungsvariable - Benannte Zeichenketten, die für alle Anwendungen verfügbar sind

Beschreibung

Variablen

Variablen werden verwendet, um das Verhalten jeder Anwendung an die Umgebung, in der sie läuft, anzupassen

Anpassungen

Pfade für Dateien
Sprachoptionen
...

Im Handbuch jeder Anwendung sollte stehen, welche Variablen von dieser Anwendung verwendet werden

Standardvariablen

Es gibt jedoch einige Standardvariablen in Linux-Umgebungen

Option	Beschreibung
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

Anzeigen

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

$ env

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

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, sodass sie automatisch verfügbar sind

Leider ist dies nicht immer so einfach, wie es klingt
Und warum? Dafür gibt es mehrere Gründe

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
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
Einige Desktop-Umgebungen starten Programme über einen Hilfsdienst, sodass 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

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

Aufruf

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

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

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

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

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

PAM kann login anweisen, auch die Variablen in /etc/environment zu lesen
Dies ist die Voreinstellung

Die Login-Shell startet und liest ihre shellspezifischen Konfigurationsdateien

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

sshd hat eine Startumgebung, die durch seine Servicedatei definiert ist
PAM kann zusätzliche Variablen bereitstellen
/etc/ssh/sshd_config definiert zusätzliche Umgebungsvariablen, die vom Client akzeptiert werden können
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

Am Ende des Bootens wird die Mutter aller Prozesse -- init -- gestartet
init führt Dienste wie oben beschrieben aus

Einer dieser Dienste wird Ihr DisplayManager sein

Wenn sich der Benutzer erfolgreich anmeldet, prüft der Display-Manager PAM und startet dann eine Xsession
- PAM kann den DM anweisen, die Variablen aus /etc/environment zu lesen
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?

Konfiguration

Dateien

Anhang

Siehe auch

Linux/Umgebung/Variable

env

Dokumentation

Man-Page

DebianMan:7/environ|environ(7)

Info-Pages

Links

Weblinks