it-swarm.com.de

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 auf dem Weg ist? Wenn ja, wie könnte das sein und warum? Ich würde mehr Tests durchführen, um das zu überprüfen, aber ich denke, er hat es jetzt satt und möchte wieder arbeiten .)

43
skiphoppy

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 Benutzer- Umgebungsvariable 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.

37
JPaget

Ü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 gesetzt 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 Option reg add /t REG_EXPAND_SZ an.

15
climenole

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 wurde ebenfalls nicht erweitert. Dies bedeutete, dass ich keine Programme ausführen konnte, für die ein 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 Teildes Pfades zu löschen, so 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 Verarbeitung, die zum ordnungsgemäßen Erweitern der Pfade mit Leerzeichen erforderlich ist.

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).

9
RobDavenport

ich habe dies in den Microsoft-Foren im März 2009 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:

alt text

Und ich füge meine Variable dem Pfad hinzu:

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

Wenn Sie dann 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:

alt text


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

7
Ian Boyd

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.

5
Sekhat

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.

2
Justin

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".

2
Nij

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 dadurch alle verschachtelten Verweise auf Umgebungsvariablen neu ausgewertet.

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

1
BAP

PATH ist die Verkettung der Benutzer-PATH-Variablen, gefolgt von der globalen PATH-Variablen. Um eine Variable in einer anderen zu verwenden, muss diese bereits gesetzt sein. Benutzervariablen werden vor globalen Variablen gesetzt (zumindest hier in meinem 64-Bit-Windows 7), daher können Sie in Ihrer Benutzer-PATH-Variablen keine globalen Variablen verwenden. Darüber hinaus werden Variablen in alphabetischer Reihenfolge festgelegt, sodass Sie dies ebenfalls berücksichtigen müssen.

1
cbarrick

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

von einer cmd-Eingabeaufforderung

set /? 

lesen Sie den Abschnitt mit der Beschreibung der "verzögerten Umgebungsvariablenexpansion", der ein kleines zu testendes Beispiel 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)

1
libjack

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 von %ProgramFiles%\Something zu den Benutzern PATH führt immer zu einer erwarteten Erweiterung von %ProgramFiles%, sofern dies in der Maschinenumgebung unter definiert wurde den Zeitpunkt der Benachrichtigung über eine variable Änderung (fälliger Ladeauftrag - 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 passiert).

1
user539484

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

Es gibt zwei Bereiche: Benutzer- und globale Variablen (Benutzer ist Ihr Windows-Benutzername) und Systemvariablen sind globale Variablen. Wenn Sie also in Benutzervariablen wie Java_HOME 'Neu' festlegen und den Pfad darunter einfügen, werden Variablen auch dann festgelegt, wenn Sie global sind Pfad enthält Programmdateien im Ordner.

0
thunder_nemesis

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 Kommandozeilenfenster, wieder PATH, gleicher Wert ... wie erwartet (aus Erfahrung!).

Ich öffne ein neues Befehlszeilenfenster, tippe PATH, 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 Programm, das sich gut verhält, 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

0
PhiLho