Umgebungsvariablen
Umgebungsvariablen enthalten Informationen in Form von Zeichenketten. Dies sind meist Pfade oder Programmoptionen, sowie Informationen über bestimmte Dinge. Umgebungsvariablen stehen im Regelfall allen Programmen zur Verfügung, die als Kindprozesse des Programmes, das die Variable gesetzt hat.
Alle Umgebungsvariablen können angepasst werden. Wenn es sich um einen user-Account handelt, natürlich nur userbezogen. Mit dem root-Account sind selbstverständlich systemweite Anpassungen möglich – die allerdings von Usern wieder userbezogen angepasst werden können.
Man sollte Variablen, sofern nichts elementar Wichtiges dagegen spricht immer nur userbezogen setzen. So kann man sich sicher sein, dass das System auch bei fehlerhaften Variablen noch einwandfrei funktioniert, und man als root noch problemlos auf dem System arbeiten, und die fehlerhaften Variablen korrigieren, kann.
Variablen setzen
Es gibt zwei Arten, Umgebungsvariablen zu setzen. Zum einen können sie direkt gesetzt werden, zum anderen können sie exportiert werden. Direkt gesetzte Variablen sind nur in dem Programm verfügbar, in dem die Variable gesetzt wurde. Exportierte Variablen sind zudem auch Kindprozessen dieses Programms verfügbar.
Nachfolgendes Beispiel demonstriert in der bash anhand der Variablen „VAR“, wie eine Umgebungsvariable gesetzt wird. Für andere Shells wird dies ganz ähnlich gelten. Bei der CSH und Shells, die auf der CSH basieren, werden Variablen mit setenv gesetzt.
$ VAR="der Wert" $ echo $VAR der Wert $ bash -c 'echo $VAR' export VAR="der Wert" $ bash -c 'echo $VAR' der Wert $
Zuerst wird die Variable direkt gesetzt und ausgegeben. Danach wird versucht, die Variable in einem Kind-Prozess, hier der bash, auszugeben (zur Syntax der Befehlsübergabe an die bash beim Starten siehe Wiki-Artikel über die Bash). Da die Variable nur dem aktuellen Prozess zur Verfügung steht, schlägt dies fehl.
Für den zweite Versuch wird die Variable exportiert. Sie steht nun nicht nur in der bash-Instanz zur Verfügung, in der die Variable gesetzt wurde, sondern auch allen Kindprozessen dieser Instanz. Im Beispiel wird eine zweite bash gestartet und durch das echo die Variable ausgeben, was nun funktioniert.
Variablen ändern
Es können nicht nur neue Variablen gesetzt werden, sondern, da Neudefinitionen vorhandene Definitionen überschreiben, auch Variablenwerte „geändert“ werden. Man sollte allerdings vorsicht walten lassen, wenn man vom System gesetzte Umgebungsvariablen anpasst. Zwar ist dies meist weniger Kritisch, da Änderungen nur für die aktuelle Instanz und dessen Kindprozesse gelten, aber es ist trotzdem ärgerlich.
Man sollte daher Variablen-Änderungen oder neue Variablen nicht sofort in die Automatisch ausgeführten Dateien schreiben, sondern davor erst einmal testen. Wenn dann etwas nicht funktionieren sollte, betrifft dies nur die aktuelle Instanz.
Variablen können auch „on-the-fly“ für nur einen einzigen Programmaufruf verwendet werden, indem man die Variablendefinition dem Programmaufruf voranstellt.
$ export VISUAL=/gibt/es/nicht $ crontab -e /bin/sh: /gibt/es/nicht: Datei oder Verzeichnis nicht gefunden $ VISUAL=vi crontab -e [vi öffnet sich mit der Crontab des users] $ echo $VISUAL /gibt/es/nicht $
Zuerst wird die Variable „VISUAL“ mit einem Pfad belegt, der nicht existiert. Ein darauf folgender Versuch, die Crontab des users zu editieren schlägt fehlt, da crontab VISUAL auswertet. Wenn man nun VISUAL direkt vor dem aufruf von crontab definiert, funktioniert es, obwohl die Variable nach-wie-vor mit „/gibt/es/nicht“ belegt ist.
Ausgabe von Variablen
Neben der vom user oder von root gesetzten Variablen gibt es auch diverse Variablen, die vom System selbst definiert werden. Um alle exportierten Variablen anzuzeigen, kann man sich des Programms env bedienen. Dies listet alle Variablen unsortiert auf.
$ env XDG_DATA_HOME=/home/dirk/.local/share SHELL=/bin/bash TERM=xterm HISTSIZE=1000 QT_XFT=true VAR=der Wert WINDOWID=35651606 HUSHLOGIN=FALSE QTDIR=/opt/qt XTERM_SHELL=/bin/bash [weitere Variablen]
env unterscheidet bei der Ausgabe nicht, ob es sich um Variablen handelt, die vom Benutzer (egal, ob root oder user) gesetzt wurden, oder ob sich um Variablen handelt, die vom System gesetzt wurden. Bei der Verwendung der Variablen hat dies ebenfalls keine Bedeutung.
Standard-Variablen
In diesem Abschnitt des Wiki-Artikels werden einige der Standard-Variablen beschrieben, die auf jedem System vorhanden sind. Es gibt darüber hinaus noch weitere Variablen, auf die hier allerdings nicht näher eingegangen wird.
Zu jeder Variablen gibt es einige Informationen über den Verwendungszweck, sowie Informationen über die Auswirkungen bei Änderung der Werte.
PATH
Eine der wichtigsten Umgebungsvariablen ist „PATH“. PATH gibt an, unter welchem Pfad Programme liegen. Die Variable wird vom System automatisch gesetzt, und sollte vom Benutzer nur angepasst, nie aber komplett ersetzt werden. In dieser Variablen werden Pfade mittels Doppelpunkt getrennt dargestellt.
$ echo $PATH /bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/core:/opt/qt/bin
Wenn man diese Variable nun um das Verzeichnis „/usr/local/bin“ erweitern möchte, weil man dort selbstkompilierte Programme und selbstgeschriebene Scripte ablegen und einfach ausführen möchte, ergänzt man den Pfad um diesen Eintrag.
export PATH=$PATH:/usr/local/bin
Man setzt hiermit PATH neu, und zwar zuerst mit dem aktuellen Inhalt dieser Variablen, und dann, durch Doppelpunkt getrennt, mit dem zusätzlichen Pfad. Suchpfade werden immer von Links nach rechts nach dem Programmnamen durchsucht. Zu anfang sollten daher immer die Standard-Programmpfade stehen.
$ man Welche Manual-Seite wollen Sie haben? $ PATH=/bin/false $ man bash: man: Kommando nicht gefunden.
Durch das fehlerhafte Setzen der Programmsuchpfad-Variablen nimmt man der aktuellen bash-Instanz die Möglichkeit, Programme auszuführen. Wenn man dies in die globale Konfigurationsdatei der bash schreibt, kommt man nur noch über Umwege wieder zu einem funktionierenden System.
HOME
Eine ebenfalls sehr wichtig Variable ist „HOME“. Über diese Variable wird dem System mitgeteilt, welches das home-Verzeichnis des entsprechenden users ist. Da praktisch alle Programme beim Speichern von Optionen auf diese Variable zugreifen, sollte man sie unter gar keinen Umständen direkt manipulieren, sondern dafür immer die Userverwaltung verwenden.
$ cd $ pwd /home/user $ HOME=/usr $ cd $ pwd /usr $
Hier wird mittels einem einfachen cd in das dem User zugewiesene home-Verzeichnis gewechselt. Dies wird mittels pwd angezeigt. Danach wird die Variable „HOME“ auf „/usr“ geändert. Mittels eines einfachen cd wird nun wieder in das dem User zugewiesene home-Verzeichnis gewechselt, und dieses dann erneut mittels pwd angezeigt.
Es gibt keinen Grund, diese Variable manuell zu manipulieren, sie kann aber zum beispiel in Shellscripts oder in Programmen Verwendet werden, um relativ einfach, userunabhängig, auf das home-Verzeichnis zuzugreifen.
Diese Variable ist eine Standard-Variable unter Linux und sogar auf Embedded-Systemen verfügbar, wohingegen „~“ nicht immer und überall das home-Verzeichnis referenziert.
PS1 bis PS4
Das Eingabeprompt, sowie dessen neue Zeilen, etc. werden den Variablen PSn definiert, wobei n eine Zahl von 1 bis 4 ist. Die Standard-Belegung unter Arch lautet wie folgt.
PS1="[\u@\h \W]\$ " PS2="> " PS3="> " PS4="+ "
Ändert man diese Variablen, wird das Prompt andersartig angezeigt. Vor allem PS1, durch welche das Standard-Eingabeprompt definiert wird, wird häufig angepasst, um das System zu personalisieren. Um diese Variable „dauerhaft“ anzupassen, wird die Änderung für gewöhnlich in die bashrc des user-Accounts geschrieben, für den der Anwender eine Änderung vornehmen möchte.
Der Wiki-Artikel Bash-Prompt_anpassen zeigt, wie PS1 manipuliert werden kann, um das Prompt zu verändern.
DISPLAY
Über die „DISPLAY“-Variable wird den Programmen mitgeteilt, auf welchem Bildschirm sie dargestellt werden sollen. Diese Variable wird vom System gesetzt, und ist vor allem bei grafischen Benutzerschnittstellen mit mehreren Monitoren, oder bei der Arbeit per SSH von Bedeutung.
Um zum Beispiel von einem per SSH erreichbaren Rechner mittels „scrot“ einen Screenshot des aktuellen X-Servers zu machen, muss man die Variable verwenden.
$ scrot giblib error: Can't open X display. It *is* running, yeah? $ DISPLAY=:0.0 scrot $
Programme werden immer auf dem angegebenen Bildschirm geöffnet. Im Falle des Beispiels wird lediglich ein Screenshot angefertigt. Wenn man zwei Bildschirme verwendet, kann man so zum Beispiel eine zweite Openbox-Instanz auf dem zweiten Monitor betreiben.
DISPLAY=:1.0 openbox
Openbox startet nun auf dem Zweiten Bildschirm, und kann nahezu unabhängig vom ersten Bildschirm, bzw. dem da laufenden Fenstermanager verwendet werden. Die Monitore werden von 0 aufsteigend nummeriert. „:1.0“ entspricht also dem zweiten Bildschirm, bzw. dem zweiten definierten Monitor.
LANG
Über die LANG-Variable werden die zur Ausgabe verwendete Sprache sowie das entsprechende Encoding definiert. Dies Betrifft jedoch lediglich die Anzeige. Optionen und Konfigurationsdateien werden davon normaler Weise nicht beeinflusst. LANG ist vor allem dann wichtig, wenn man Fehleranalyse betreiben will, und man dazu die Original-Fehlermeldungen, statt der übersetzten Texte sehen möchte.
$ df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf [Informationen über den Speicherplatz] $ LANG=C df -h Filesystem Size Used Avail Use% Mounted on [Informationen über den Speicherplatz]
Zuerst wird der Befehl df -h ganz normal eingegeben, und entsprechend der Systemeinstellungen auf Deutsch ausgeben. Beim zweiten Aufruf wird dem Befehl ein „LANG=C“ vorangestellt, das bestimmt, dass die Ausgabe unformatiert vorgenommen werden soll. Entsprechend wird die Ausgabe von df -h nun auf Englisch dargestellt.
Es können alle locales Verwendet werden, die auf dem System vorhanden sind.
grep -v '^#' /etc/locale.gen | sed s/" .*"/""/g
Dieser Befehl gibt je Zeile eine locale aus. locales werden in der Datei „/etc/locales.gen“ definiert. Definitionen mit vorangestellter Raute werden beim generieren Ignoriert. Will man eine locale verwenden, wird die Raute entfernt. Danach erstellt man als mittels locale-gen die neuen locales.
