Umgebungsvariable

Als Umgebungsvariable bezeichnet man konfigurierbare Variablen in Betriebssystemen, die oft Pfade zu bestimmten Programmen oder Daten enthalten, sowie bestimmte Daten und Einstellungen, die von mehreren Programmen verwendet werden können. In der Regel handelt es sich um Zeichenketten.

Eine andere Bezeichnung ist auch globale Variable; allerdings ist das eher unüblich, da dies in vielen Programmiersprachen in einer anderen Bedeutung verwendet wird.

Benutzer oder Anwendungen können Werte dieser Variablen lesen und/oder verändern.

Unix und Unix-ähnliche Betriebssysteme

Kommandozeile

In vielen auf UNIX basierenden Betriebssystemen, etwa macOS, Linux oder BSD,^[1] werden Umgebungsvariablen beim Start eines Kommandozeileninterpreters (Shell) gesetzt. Vordefinierte Umgebungsvariablen werden in der Regel beim Start einer Shell gemäß den Einträgen in einer oder auch mehreren Konfigurationsdateien automatisch gesetzt. In der Bourne-Shell ist dies beispielsweise die Datei /etc/profile. Zusätzlich benutzt die Shell eine im Heimatverzeichnis des Benutzers vorhandene Datei (z. B. .profile oder .cshrc), die benutzerspezifische Umgebungsvariablen enthält und vom Benutzer selbst angepasst werden kann. Diese vordefinierten Umgebungsvariablen kann man sich durch die Eingabe von printenv in der Shell auch ausgeben lassen. Das Programm env zeigt alle Umgebungsvariablen an oder lässt ein Programm in einer veränderten Umgebung laufen. Beide Befehle sind Bestandteil der coreutils.

Vordefinierte Umgebungsvariablen

Einige Umgebungsvariablen finden sich auf fast allen Unix-Systemen wieder. Beispiele hierfür sind:

`HOME`	Der Pfad des persönlichen Verzeichnisses des aktuellen Benutzers
`LOGNAME`	Der Name des aktuellen Benutzers
`MAIL`	Der Pfad, in dem die persönlichen E-Mail-Nachrichten des aktuellen Benutzers abgelegt werden
`PATH`	Diese Variable enthält den Suchpfad. Sollte bei der Eingabe eines Befehls kein Verzeichnis angegeben werden, durchsucht die Shell die in dieser Variable gespeicherten Pfade von links nach rechts. Die Verzeichnisnamen werden unter unixoiden Betriebssystemen durch Doppelpunkt „:“ getrennt. Das aktuelle Verzeichnis wird nicht durchsucht, da dies ein Sicherheitsrisiko darstellt.

Änderung der Umgebungsvariablen

Umgebungsvariablen können folgendermaßen gesetzt und den anderen Prozessen innerhalb des Betriebssystems bekannt gemacht werden:

Bei Bourne, bash und darauf aufbauenden Shells:

Setzen der Variable:	`<Variablenname>=<Variableninhalt>`
Bekanntmachen der Variable:	`export <Variablenname>`
Löschen der Variable:	`unset <Variablenname>`

Bei csh, tcsh und darauf aufbauenden Shells:

Setzen und Bekanntmachen der Variable:	`setenv <Variablenname> <Variableninhalt>`

Anzeigen von Umgebungsvariablen

Anzeigen aller Umgebungsvariablen

Abfrage der Variable:	`env`

Anzeigen einer bestimmten Umgebungsvariablen

Bei allen Shells:

Abfrage der Variable:	`echo $<Variablenname>`

Prozessabhängigkeit

Es ist üblich, dass die Umgebungsvariablen pro System-Prozess gespeichert werden. Änderungen, die ein Prozess an den Variablen vornimmt, sind nur für ihn selbst gültig und für Prozesse, die von ihm nach der Änderung gestartet werden (Child-Prozesse).

DOS und Windows

Die Funktionalität unter MS-DOS (und kompatiblen DOS) und Windows ist gleich. Der Umfang an Funktionen und Standardvariablen ist bei Windows allerdings größer. Auch können Variablen unter Windows nicht nur system- bzw. umgebungsweit gesetzt werden (z. B. per Systemsteuerung), welche von sämtlichen Sub-Prozessen genutzt werden können, sondern auch auf eine einzelne Sitzung eines gestarteten Sub-Prozesses beschränkt sein. Ein Sub-Prozess übernimmt zunächst alle Variablen der übergeordneten Umgebung (environment) bzw. des aufrufenden übergeordneten Prozesses (z. B. COMMAND.COM, CMD.COM, Explorer.exe oder andere) in sein Umgebungssegment (worauf ein Zeiger im PSP an Adresse 2Ch verweist), welches darauf folgend um weitere Variablen erweitert werden kann. Das Umgebungssegment eines (Sub-)Prozesses besteht ausschließlich während dessen Laufzeit und verfällt bei seiner Beendigung.

Setzen

Umgebungsvariablen können von der Befehlszeile aus oder aus Stapelverarbeitungsdateien (.cmd, .BAT) mit dem SET-Befehl gesetzt werden (z. B. SET PROMPT=$P$G). Wird der SET-Befehl alleine angegeben, werden alle Umgebungsvariablen angezeigt. Das Angeben des Namens einer Variablen mit bspw. SET Variablenname führt in MS-DOS bis einschließlich Version 8.0 zu einer Syntax error Meldung, in Windows NT und FreeDOS kann aber so deren Wert angezeigt werden. Löschen kann man sie, indem der Variablenname gefolgt von = angegeben wird (z. B. SET PROMPT=).

Abfrage

In Stapelverarbeitungsdateien (.BAT) können Umgebungsvariablen eingesetzt werden, indem sie in Prozentzeichen eingeklammert werden (z. B. CD %VARIABLE%). Das aufgerufene Programm erhält dann die Befehlszeile mit substituierter Variable.

Setzen aus Programmen heraus

Der Mechanismus der Umgebungsvariablen sieht nicht vor, dass aus einem Programm oder einer geschachtelt aufgerufenen Shell- (Cmd-) Umgebung heraus die Umgebungsvariablen der übergeordneten Shell geändert werden können. Aufgrund der Vererbung von Variablen wirken sich Veränderungen an der eigenen Umgebung nicht auf die Umgebung der COMMAND.COM (Master Environment) aus. Auch ein Aufruf des Befehlszeilenbefehls SET aus einem Programm heraus hat keine Wirkung, da dies eine neue Instanz der COMMAND.COM startet.

Folgender Trick war unter DOS und älteren Windows-Versionen möglich: Die Umgebung der COMMAND.COM konnte verändert werden, indem man über den ersten Speichersteuerblock über INT 21 AH=52h an Adresse [BX-2h] findet, und dann Speichersteuerblock für Speichersteuerblock durchsucht, bis man die Umgebung der COMMAND.COM findet und diese verändert. Das funktioniert allerdings nicht mehr ab Windows NT, da dort die Umgebung der COMMAND.COM regelmäßig vom NT-Kernel neu geladen wird.

Die Festlegung einer Umgebungsvariable in einem Programm und folgende Verwendung in einem Shell- oder Batch-Script ist möglich, indem in dem Programm nach Ändern der eigenen Umgebung das Shell oder Batch-Script aus diesem Programm heraus gestartet wird. Ein solcher Aufruf wird in der Regel in Programmiersprachen mittels Aufruf der jeweiligen Betriebssystem-Funktion unterstützt, in Java beispielsweise mit der Klasse java.lang.ProcessBuilder. Die geänderte Umgebung des Programmes wirkt dann als parent für diesen Aufruf.

In Windows-Batch-Programmen und unter PC-kompatiblem DOS wirkt die Änderung der Umgebung einer gerufenen Batch (call-Befehl) auf die rufende Ebene, weil die COMMAND-Umgebung damit nicht verlassen wird. Das gilt nicht für den Aufruf eines Unix-Shell-Scripts aus einem Script. Das aufgerufene Script wird in eine neue (child-)Umgebung eingebettet, die also nicht für die rufende Ebene gilt.

In Windows ist es nun möglich, aus einem Programm heraus die Umgebung dennoch zu beeinflussen: Das Programm muss eine kleine Batch-Datei in einem Temp-Verzeichnis oder dem aktuellen Verzeichnis mit folgendem Inhalt erzeugen:

set VARIABLE=WERT

Dieses temporäre Batchfile wird dann im Gesamtbatch nachfolgend aufgerufen:

mysetenv.exe someparameters >setenv.bat
call setenv.bat
folgende batch-befehle

Windows-Kommandozeile

Um sich in der Kommandozeile den Wert einer Umgebungsvariable anzeigen zu lassen, verwendet man echo %NAME% oder set NAME, wobei für NAME der Variablenname eingesetzt wird. Der set-Befehl steht ferner als Kommandozeilen-Editor zur Verfügung. Er lässt sich auch sehr gut innerhalb von Batch-Dateien verwenden. Der Befehl set als solcher listet alle gesetzten und somit verfügbaren Umgebungsvariablen auf. Möchte man eine Umgebungsvariable erstellen oder einer bestehenden einen neuen Wert zuweisen, nutzt man set NAME=WERT, wobei statt NAME der Name und statt WERT der künftige Wert der Variablen eingesetzt wird. set /? gibt ausführliche Informationen zu den Funktionalitäten des Befehls.

Grafische Oberfläche

Einen grafischen Editor zum direkten Bearbeiten der Umgebungsvariablen bietet der Befehl rundll32 sysdm.cpl,EditEnvironmentVariables oder der Menüpunkt „Systemsteuerung – System“ oder die Tastenkombination Windows+Pause. Der Editor ist unter dem Register „Erweitert“ und dort unter „Umgebungsvariablen“ zu finden.

Benutzervariablen und Systemvariablen

Neuere Windowsversionen (beispielsweise Windows XP oder Windows 7) unterscheiden zwischen „Benutzervariablen“, die sich nur auf den momentan eingeloggten Benutzer beziehen, und „Systemvariablen“, die für das gesamte System (also auch alle übrigen Benutzerkonten) gültig sind.

Dynamische Umgebungsvariablen

Einige DOS- und Windows-Programme stellen von sich aus dynamisch generierte Umgebungsvariablen zur Verfügung. Diese werden nicht fest gespeichert, und der Wert wird kurz vor der Ausgabe ermittelt. Beispiele solcher dynamischer Umgebungsvariablen sind:

CD	Gibt das Verzeichnis an, in dem sich der Abfragende gerade befindet. (auch DOS; klassisch: ohne Laufwerksbuchstaben; ab etwa Windows XP: mit Laufwerksbuchstaben)
DATE	Aktuelles System-Datum
TIME	Aktuelle System-Zeit
ERRORLEVEL	Fehlercode des zuletzt ausgeführten Befehls (auch DOS)
RANDOM	Generiert eine Zufallszahl zwischen 0 und 32767
CMDCMDLINE	Enthält die Befehlszeile des aktiven Kommandointerpreters, siehe auch COMSPEC

Vordefinierte Umgebungsvariablen

Abhängig von der verwendeten Windows-Version stehen weitere, beim Systemstart oder beim Einloggen definierte Umgebungsvariablen bereit. Die Werte können von der Landessprache und von dem Laufwerksbuchstaben des Betriebssystemlaufwerkes abhängen. Zum Beispiel:

Variable	Windows (ab Vista)	Bemerkung ¹
%ALLUSERSPROFILE% oder %PROGRAMDATA%	C:\ProgramData	lokalisiertes Windows XP: C:\Dokumente und Einstellungen\All Users
%APPDATA%	C:\Users\{username}\AppData\Roaming	lokalisiertes Windows XP: C:\Dokumente und Einstellungen\{username}\Anwendungsdaten
%COMPUTERNAME%	{computername}
%COMMONPROGRAMFILES%	C:\Program Files\Common Files	lokalisiertes Windows XP: C:\Programme\Gemeinsame Dateien
%COMMONPROGRAMFILES(x86)%	C:\Program Files (x86)\Common Files	lokalisiertes Windows XP: C:\Programme (x86)\Gemeinsame Dateien
%COMSPEC%	%SystemRoot%\System32\cmd.exe	Pfad zum Kommandozeilen-Interpreter (auch unter DOS); %SystemRoot% entsprechend expandiert
%HOMEDRIVE%	C:
%HOMEPATH%	\Users\{username}	lokalisiertes Windows XP: \Dokumente und Einstellungen\{username}
%LOCALAPPDATA%	C:\Users\{username}\AppData\Local
%LOGONSERVER%	\\{domain_logon_server}
%OS%	Windows_NT
%PATH%	%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem	Suchpfad ^PATH; %SystemRoot% entsprechend expandiert auch DOS
%PATHEXT%	.com, .exe, .bat, .cmd, .vbs, .vbe, .js, .jse, .wsf, .wsh, .msc	(Windows XP: gleich, außer .jse und .msc)
%PROGRAMFILES%	C:\Program Files	lokalisiertes Windows XP:^[2] C:\Programme
%PROGRAMFILES(X86)%	C:\Program Files (x86)	lokalisiertes Windows XP:^[3] C:\Programme (x86)
%PROMPT%	$P$G	Prompt; seit PC DOS bzw. MS-DOS
%SystemDrive%	C:
%SystemRoot%	C:\Windows	Windows NT vor Windows 2000: C:\WINNT
%TEMP% oder %TMP%	C:\Users\{username}\AppData\Local\Temp	^TEMP; lokalisiertes Windows XP: C:\Dokumente und Einstellungen\{username}\Lokale Einstellungen\Temp
%USERDOMAIN%	{userdomain}
%USERNAME%	{username}	Der Name des aktuellen Benutzers
%USERPROFILE%	C:\Users\{username}	lokalisiertes Windows XP: %SystemDrive%\Dokumente und Einstellungen\{username}
%WINDIR%	C:\Windows	Historische Form (16-Bit-Windows), zur Kompatibilität beibehalten. Muss immer identisch mit %SystemRoot% sein.
%PUBLIC%	C:\Users\Public
%PSModulePath%	%SystemRoot%\system32\WindowsPowerShell\v1.0\Modules\	bei installierter PowerShell

¹

Wenn nicht in den Bemerkungen extra angeführt, gibt es alle gelisteten Variablen erst ab Windows Vista.

^PATH

Durch Semikolon getrennte Pfade, in denen in dieser Reihenfolge ausführbare Programme gesucht werden sollen, wenn ein Befehl nicht im aktuellen Verzeichnis gefunden werden konnte. Daneben gibt es einen weiteren Mechanismus der Programmregistrierung.

^TEMP

Zum Datenschutz sollte dies möglichst nicht ein allgemeines Verzeichnis für alle Benutzer sein, sondern ein spezifisches Benutzerverzeichnis; etwa %HOMEDRIVE%%HOMEPATH%\TEMP.

Registrierung

Unter den neueren auf NT basierenden Versionen von Windows (Windows NT/2000/XP/2003/Vista) werden Umgebungsvariablen in der Registrierung gespeichert. Der Registrierungspfad

 HKEY_CURRENT_USER\Environment

bzw. bei Windows XP (für z. B. HOMEDRIVE) und Windows Vista

 HKEY_CURRENT_USER\Volatile Environment

wird für Umgebungsvariablen verwendet, welche nur den aktuellen Benutzer betreffen. Der Pfad

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

hingegen dient zur Speicherung von Umgebungsvariablen, die im Gesamtsystem gültig sind. Mit der Suchfunktion des Registrierungseditors lassen sich die Pfade bzw. Schlüssel nach den gewünschten Einträgen durchsuchen.

Mit dem Befehl regedit im Ausführen-Dialog (Windows+R) kann der Editor gestartet werden.

Achtung: Unsachgemäße Veränderungen in der Registrierung können schwerwiegende Folgen haben. Änderungen sollten nur vorgenommen werden, wenn man weiß was man tut. Es sollte vor jeder Änderung unbedingt eine Sicherung der betreffenden Registrierungsdaten vorgenommen werden!

Verzögerung bei der Anwendung geänderter Variablen

Beim Start eines Prozesses (EXE-Datei) werden die aktuellen Umgebungsvariablen aus der Registry gelesen und dann „eingefroren“, der Prozess erhält also zu seiner Entstehung eine Kopie oder einen „Snapshot“ der aktuellen Variablen. Später geänderte Umgebungsvariablen wirken sich daher nicht auf die laufenden Prozesse aus (solange das Programm die entsprechende Windows-Botschaft nicht beachtet^[4]), sodass Prozesse wie eine laufende Shell („Eingabeaufforderung“) nichts davon mitbekommen. Sollen die Umgebungsvariablen in einer Shell verwendet werden, muss eine neue Instanz der Shell geladen werden. Es spielt dabei keine Rolle, ob eine bereits geöffnete Shell mit den alten Umgebungsvariablen vorher geschlossen wurde oder nicht. Es können dadurch zwei Shells mit unterschiedlichen Umgebungsvariablen ausgeführt werden.

Wird die Shell aus einem Windows-Explorer heraus gestartet (z. B. mittels „Open Command Window here“), und ist die Option „Ordnerfenster in einem eigenen Prozess starten“ in der Einstellung des Windows-Explorers aktiviert, so muss auch der Windows-Explorer neu gestartet werden, damit die geänderten Einstellungen sichtbar werden.

Siehe auch

Sonderverzeichnis, thematisch verwandt zu den Umgebungsvariablen in Windows

Weblinks

Why are there separate Program Files and Program Files (x86) directories? by Raymond Chen (englisch)

Einzelnachweise

↑ Umgebungsvariable › Wiki › ubuntuusers.de. Abgerufen am 25. Oktober 2023.
↑ https://devblogs.microsoft.com/oldnewthing/20220329-00/?p=106404 Why are there separate Program Files and Program Files (x86) directories? by Raymond Chen (englisch)
↑ https://devblogs.microsoft.com/oldnewthing/20220329-00/?p=106404 Why are there separate Program Files and Program Files (x86) directories? by Raymond Chen (englisch)
↑ Karl-Bridge-Microsoft: WM_SETTINGCHANGE Nachricht (Winuser.h) - Win32 apps. 13. Juni 2023, abgerufen am 25. Oktober 2023 (deutsch).

[1] Umgebungsvariable › Wiki › ubuntuusers.de. Abgerufen am 25. Oktober 2023.

[2] ttps://devblogs.microsoft.com/oldnewthing/20220329-00/?p=106404 Why are there separate Program Files and Program Files (x86) directories? by Raymond Chen (englisch)

[3] ttps://devblogs.microsoft.com/oldnewthing/20220329-00/?p=106404 Why are there separate Program Files and Program Files (x86) directories? by Raymond Chen (englisch)

[4] Karl-Bridge-Microsoft: WM_SETTINGCHANGE Nachricht (Winuser.h) - Win32 apps. 13. Juni 2023, abgerufen am 25. Oktober 2023 (deutsch).

[1]

[2]

[3]

[4]