Warum kann Windows eine Umgebungsvariable in Path nicht verarbeiten?

Mein Kollege und ich haben identische Dell Workstations mit Windows XP Professional x64 Edition installiert.

Die Umgebungsvariable "Mein Pfad" beginnt mit:

%JAVA_HOME%\bin;...

Die Pfadvariable meines Kollegen enthält dasselbe Verzeichnis, das mit derselben Umgebungsvariablen angegeben wurde, ist jedoch nicht das erste Element in seinem Pfad.

Wenn ich auf Systemeigenschaften -> Umgebungsvariablen zugreife und den Wert meiner JAVA_HOME-Variablen ändere, ändert sich die über die Befehlszeile gefundene Java-Version wie erwartet. Dies startet ein brandneues Konsolenfenster, um sicherzugehen, dass die Änderungen übernommen werden.

Auf der Maschine meines Kollegen ist dies jedoch nicht der Fall. Er findet weiterhin seine vorherige Java-Version, bis er seine Pfadvariable aufruft und speichert (auch wenn er keine Änderungen daran vornimmt). (Auch dies ist beim Starten eines brandneuen Konsolenfensters der Fall.)

Ich beobachte diese Inkonsistenz unter Windows seit ungefähr 6 Monaten und bin sehr neugierig darauf. Wir haben viel zu viele Windows-Versionen in unserem Büro, so selten hatte ich bisher die Gelegenheit, dies auf zwei Rechnern mit genau der gleichen Betriebssystemversion zu beobachten.

Was verursacht das? Warum wertet sein Computer Path mit dem neuen JAVA_HOME nicht neu aus, wenn meins dies tut?

(Liegt es daran, dass es nicht das erste ist, was auf dem Weg ist? Wenn ja, wie könnte das sein und warum? Ich würde mehr Tests durchführen, um dies zu überprüfen, aber ich denke, er hat jetzt die Nase voll und möchte wieder an die Arbeit .)

Ihr Pfad ist die Verkettung des Systempfads, gefolgt vom Benutzerpfad. Darüber hinaus enthalten Systemumgebungsvariablen möglicherweise keine Verweise auf Benutzerumgebungsvariablen, und solche Verweise werden nicht erweitert. Um das gewünschte Ergebnis zu erhalten, fügen Sie den Verweis auf% JAVA_HOME% in die Benutzerumgebungsvariable PATH ein oder erstellen Sie eine solche Variable, falls sie noch nicht vorhanden ist.

Vielleicht macht ein vereinfachtes Beispiel dies klarer. Angenommen, die SYSTEM-Umgebung ist

ProgramFiles = C:\Program Files
SystemRoot = C:\WINDOWS
PATH = %SystemRoot%\SYSTEM32

und die Umgebung des Benutzers JSmith ist

JAVA_HOME = %ProgramFiles%\Java\bin
USERPROFILE = C:\USERS\JSmith
PATH = %JAVA_HOME%\bin;%USERPROFILE%\bin

dann wäre der resultierende Pfad

C:\WINDOWS\SYSTEM32;C:\Program Files\Java\bin;C:\Users\JSmith\bin

wie gewünscht.

Überprüfen Sie in der Windows-Registrierung unter diesem Schlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Environment

WENN die Umgebungsvariable erweitert werden muss (hier:% JAVA_HOME%)

dann muss die Variable als REG_EXPAND_SZ- Wert festgelegt werden.

Wenn Sie reg.exe über die Befehlszeile zum Hinzufügen / Bearbeiten von Registrierungswerten verwenden, wird standardmäßig REG_SZ eingegeben. Geben Sie den Typ REG_EXPAND_SZ mit der reg add /t REG_EXPAND_SZOption an.

Es gibt ein bestimmtes Problem beim Erweitern von Umgebungsvariablen in der PATH-Variablen, wenn die Variable auf einen Pfad erweitert wird, der Leerzeichen enthält.

Wir haben unsere eigenen Variablen auf Systemebene wie "OUR_ROOT = c: \ MyRoot" erstellt und sie dann im Systempfad wie "PATH =;% OUR_ROOT% \ bin;" verwendet. und das wird korrekt zu "PATH =; c: \ MyRoot \ bin;" erweitert. Bisher kein Problem.

Unter Windows 7 (32-Bit) ließ ich ein Produkt selbst installieren und Systemumgebungsvariablen wie diese erstellen:

STUDIO_BIN=C:\program files\Company Name\Product Name 10.4\bin

und es fügte es der System-PATH-Variablen hinzu:

PATH=<other path elements>;%STUDIO_BIN%;<more path elements>

Die in CMD angezeigten PATH-Werte enthielten jedoch "% STUDIO_BIN%;" und nicht der erweiterte Pfad. Der Wert unter Arbeitsplatz> Eigenschaften> Erweitert> Umgebungsvariablen blieb ebenfalls unverändert. Dies bedeutete, dass ich keine Programme ausführen konnte, für die eine DLL in diesem Verzeichnis erforderlich war.

Ändern Sie einfach STUDIO_BIN (über Arbeitsplatz> Eigenschaften> Erweitert ...> Env Vars) in einen Namen ohne eingebettete Leerzeichen:

STUDIO_BIN=C:\ProductName\bin

Nach dem Neustart des CMD-Fensters lautet der Pfad nun:

PATH=<other path elements>;C:\ProductName\bin;<more path elements>

Eine andere Lösung besteht darin, die im PATH verwendete Systemvariable im Dialogfeld Arbeitsplatz> Eigenschaften> Erweitert ...> Umgebungsvariablen ausreichend zu bearbeiten. Ich habe versucht, ein Zeichen hinzuzufügen und es zu entfernen, um eine 'Änderung' vorzunehmen, und dann habe ich OK ausgegeben, eine neue CMD-Eingabeaufforderung gestartet und PATH wurde NICHT korrekt erweitert. Ich habe dann versucht, einen Teil des Pfades so zu löschen , wie es war

STUDIO_BIN=C:\Program Files\Company Name

(Auslassen von "Product Name 10.4") und siehe da, die nächste CMD-Eingabeaufforderung zeigte PATH mit STUDIO_BIN richtig erweitert!

Seltsamerweise, wenn ich zurückkam und STUDIO_BIN den "Produktnamen 10.4" hinzufügte (einschließlich aller ursprünglich vorhandenen Leerzeichen, bevor ich anfing, mich damit zu beschäftigen) und PATH NOCH korrekt erweitert wurde.

Offensichtlich wird die PATH-Variable bei ausreichender Änderung ihres Inhalts im Dialogfeld Umgebungsvariablen einer zusätzlichen Verarbeitung unterzogen, die es ihr ermöglicht, zu arbeiten. Verarbeitung, die nicht ausgeführt wurde, als die Variable vom Installationsprogramm des Produkts hinzugefügt wurde (das wahrscheinlich nur PATH direkt in der Registrierung geändert hat).

Ich bin mir fast sicher, dass dies auch ein Problem mit XP war. In Windows 7 tauchte es gerade wieder auf, als ich eine neue Entwicklungsmaschine zusammenstellte. Anscheinend wurde es nicht von Microsoft behoben.

Anscheinend werden selbst MS-definierte Variablen wie% ProgramFiles% im PATH nicht korrekt erweitert.

Diese Seite bietet eine mögliche Antwort, wenn Sie PATH über die Befehlszeile oder die Batch-Datei festlegen. (Setzen Sie den gesamten Befehl nach SET in Anführungszeichen.) Ich weiß nicht, mit welchem ​​Installationsprogramm das von mir installierte Produkt die Umgebungsvariablen festgelegt hat, aber es ging offenbar um die erforderliche Verarbeitung, um die Pfade ordnungsgemäß mit Leerzeichen zu erweitern.

Zusammenfassend können Sie also entweder:

• Ändern Sie die Pfade (und verschieben Sie alle zugehörigen Dateien) in Pfade ohne Leerzeichen oder

• Bearbeiten Sie die Variablen, die nicht erweitert werden können, im Dialogfeld "Umgebungsvariablen" (ändern Sie sie so weit, dass sie ordnungsgemäß verarbeitet werden - ich bin mir nicht sicher, wie viel ausreicht).

Ich habe dies im März 2009 in den Microsoft-Foren gefragt und es wurde nie gelöst:

Wie verwende ich% ProgramFiles% in der Umgebungsvariablen Path? :

Ich versuche, der Umgebungsvariablen Path des Systems einen Ordner hinzuzufügen.

Ich möchte % ProgramFiles% \ SysInternals hinzufügen

auf die vorhandene Pfadvariable:

C: \ PROGRA ~ 1 \ Borland \ Delphi5 \ Projects \ Bpl; C: \ PROGRA ~ 1 \ Borland \ Delphi5 \ Bin; % SystemRoot% \ system32; % SystemRoot% ;% SystemRoot % \ System32 \ Wbem; C: \ Programme \ Microsoft SQL Server \ 80 \ Tools \ BINN; C: \ Programme \ Microsoft SQL Server \ 80 \ Tools \ Binn \; C: \ Programme \ Microsoft SQL Server \ 90 \ Tools \ binn \; C: \ Programme \ Microsoft SQL Server \ 90 \ DTS \ Binn \; C: \ Programme \ Microsoft SQL Server \ 90 \ Tools \ Binn \ VSShell \ Common7 \ IDE \; C: \ Programme \ Microsoft Visual Studio 8 \ Common7 \ IDE \ PrivateAssemblies \;% SYSTEMROOT % \ System32 \ WindowsPowerShell \ v1.0 \

Also gehe ich an die Stelle, an der du es bearbeitest:

Und ich füge meine Variable dem Pfad hinzu:

% ProgramFiles % \ SysInternals; C: \ PROGRA ~ 1 \ Borland \ Delphi5 \ Projects \ Bpl; (snip)

Wenn Sie ein neues Eingabeaufforderungsfenster öffnen, wird die Umgebungsvariable nicht durch ihren tatsächlichen Wert ersetzt:

Pfad =% ProgramFiles % \ SysInternals; C: \ PROGRA ~ 1 \ Borland \ Delphi5 \ Projects \ Bpl (snip)>

Was Sie im folgenden Screenshot sehen können:

Aber um deine Frage zu beantworten: Ich weiß es nicht. Scheint so, als ob das nicht geht.

Es gibt zwei Ebenen von Umgebungsvariablen: global und user. Wenn er% Java_home% als Benutzerumgebungsvariable festgelegt hat, aber stattdessen die globale Variable ändert, sieht er keinen Unterschied.

Stellen Sie sicher, dass der Pfad keine Leerzeichen enthält, wenn Sie Ihre eigenen Benutzerumgebungsvariablen definieren. zB: C: \ GNAT \ bin; C: \ GNAT \ include funktioniert nicht, da zwischen ";" und "C: \ GNAT \ include".

Fügen Sie die Umgebungsvariablen hinzu, während Sie mit MSTSC an der Sitzung / console angemeldet sind.

Starten Sie den Computer neu und Sie werden feststellen, dass Ihre Umgebungsvariablen bestehen bleiben.

Je nachdem, wie Sie mit dem Computer verbunden waren, als Sie versuchten, die Umgebungsvariable zu ändern, scheint es im Betriebssystem eine Eigenart zu geben.

Dies hängt möglicherweise mit der Funktion zur verzögerten Erweiterung von Umgebungsvariablen (oder mit deren Fehlen) zusammen, oder Sie können diese Funktion nutzen, um immer eine richtige Lösung zu finden.

von einer cmd-Eingabeaufforderung

set /? 

Lesen Sie den Abschnitt über die verzögerte Erweiterung von Umgebungsvariablen, der ein kleines Beispiel zum Testen enthält

set VAR=before
if "%VAR%" == "before" (
    set VAR=after
    if "%VAR%" == "after" @echo If you see this, it worked
)

Wenn Sie die Echolinie nicht erhalten, könnte das erklären ...

Wenn Sie jedoch Ihre cmd.exe mit der Option / V starten, können Sie "!" anstelle von "%", wodurch sich das Verhalten ändert

set VAR=before
if "%VAR%" == "before" (
    set VAR=after
    if "!VAR!" == "after" @echo If you see this, it worked
)

Bei mir (unter XP) funktionierte das erste Skript nicht, aber die zweite Version (mit cmd.exe / V)

Ich hatte das gleiche Problem und weiß, wie ich es beheben kann, es ist lahm.

Bearbeiten Sie einfach Ihren PFAD erneut, nehmen Sie jedoch keine Änderungen vor, und speichern Sie den PFAD erneut. Aus irgendeinem Grund werden alle verschachtelten Verweise auf Umgebungsvariablen neu ausgewertet.

Wenn es nicht mehr funktioniert, funktioniert es einfach von selbst.

Ich glaube, was Windows eine Variable in PATH nicht erweitern kann, weil es denkt, was es noch nicht definiert hat. Erwägen:

REM Ensure variable is undefined
SET UNDEFINED=
REM And then try to expand it
ECHO UNDEFINED=%UNDEFINED%

Diese Hypothese stimmt mit meiner anderen Beobachtung überein - das Hinzufügen %ProgramFiles%\Somethingzu den Benutzern PATH führt immer zu einer erwarteten Erweiterung von %ProgramFiles%, vorausgesetzt, sie wurde zum Zeitpunkt der Benachrichtigung über variable Änderungen in der Maschinenumgebung definiert (fällige Ladereihenfolge - MACHINE und dann USER). Aber wenn Sie die Maschinenumgebung ändern, geschieht die korrekte Variablenerweiterung nur beim Booten (im Moment habe ich keine Ahnung, wie und warum dies nicht regelmäßig geschieht).

Sie müssen die Reihenfolge berücksichtigen, in der die Variablen beim Anmelden festgelegt werden. Wenn Sie versuchen, eine Variable zu verwenden, bevor sie festgelegt wurde, wird sie als leere Zeichenfolge ausgegeben.

Der effektive PATH ist die Verkettung der PATH-Variablen des Benutzers, gefolgt von der globalen PATH-Variablen.

Benutzervariablen werden vor globalen Variablen gesetzt, sodass Sie in Ihrer Benutzer-PATH-Variablen keine globalen Variablen verwenden können. Darüber hinaus werden Variablen in alphabetischer Reihenfolge festgelegt, sodass Sie keine Variablen verwenden können, die vor PATH sortieren.

(Dies gilt zumindest für Windows 7. Ich habe dies nicht auf neueren Versionen getestet.)

Vielleicht machst du es falsch?

Ich habe es mit Windows XP Pro SP3 (32bit) versucht. Ich habe einen Pfad mit mehreren Vorkommen von %JAVA_HOME%(und %JAVAFX_HOME%usw.). Ich gehe zur Kommandozeile, tippe PATH, sehe die Variablen erweitert. Gut.

Ich ändere den Wert von JAVA_HOME. Zurück zum selben Befehlszeilenfenster, PATHwieder der selbe Wert ... wie erwartet (aus Erfahrung!).

Ich öffne ein neues Befehlszeilenfenster PATH, tippe, gotcha, ich sehe den neuen Wert.

Ich bin mir nicht sicher, welchen genauen Mechanismus es gibt, aber es scheint, dass jedes laufende Programm, einschließlich cmd.exe, die Werte von Umgebungsvariablen zum Startzeitpunkt erfasst und nicht zurückblickt ... (obwohl ich glaube, dass ein gut verhaltenes Programm dies kann Hören Sie auf Umgebungsänderungen (allerdings nicht sicher).

Es kann als ein Feature oder ein Bug oder Ärger gesehen werden, aber so funktioniert es. Hey, zumindest müssen wir im Gegensatz zu Win9X nicht den Computer neu starten! Und im Gegensatz zu NT-Zeiten (IIRC) müssen Sie sich nicht abmelden und zurück.

Warum die Inkonsistenz? Die Wege von Microsoft sind unergründlich ... :-P

Ich habe beschlossen, die Umgebungsvariablen unter System> Erweiterte Einstellungen> Umgebungsvariablen festzulegen .

Es gibt zwei Platten, Benutzer und globale Variablen (User sind Ihre Windows - Benutzername) und Systemvariablen sind Variablen , Global, also , wenn Sie ‚Neu‘ von Benutzervariablen, wie JAVA_HOMEund setzen Sie Ihren Weg unten, Sie Variablen , auch wenn Ihr globalen Pfad festgelegt werden habe Programmdateien im Ordner.