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
[Bearbeiten | Quelltext bearbeiten]Kommandozeile
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]Anzeigen aller Umgebungsvariablen
[Bearbeiten | Quelltext bearbeiten]Abfrage der Variable: | env
|
Anzeigen einer bestimmten Umgebungsvariablen
[Bearbeiten | Quelltext bearbeiten]Bei allen Shells:
Abfrage der Variable: | echo $<Variablenname>
|
Prozessabhängigkeit
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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) | Bemerkung1 |
---|---|---|
%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 | SuchpfadPATH; %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 |
Registrierung
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]- Sonderverzeichnis, thematisch verwandt zu den Umgebungsvariablen in Windows
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Why are there separate Program Files and Program Files (x86) directories? by Raymond Chen (englisch)
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ 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).