Warum kann Windows eine Umgebungsvariable in Path nicht verarbeiten?

67601
skiphoppy

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

Meine Umgebungsvariable Path beginnt mit:

%JAVA_HOME%\bin;...

Die Pfadvariable meines Kollegen enthält dasselbe Verzeichnis, das mit derselben Umgebungsvariablen angegeben wurde, es 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 Version von Java, die in der Befehlszeile gefunden wurde, wie erwartet. Dies startet ein brandneues Konsolenfenster, um die Änderungen zu übernehmen.

Aber auf der Maschine meines Kollegen tut es nicht. Er findet seine vorherige Java-Version weiter, bis er seine Path-Variable anzeigt und speichert (auch wenn er keine Änderungen daran vornimmt). (Dies ist wieder der Fall, wenn ein neues Konsolenfenster gestartet wird.)

Ich beobachte diese Inkonsistenz unter Windows seit etwa 6 Monaten und bin sehr neugierig. Wir haben in unserem Büro viel zu viele Windows-Versionen, daher hatte ich bisher selten die Gelegenheit, dies auf zwei Maschinen mit genau derselben Betriebssystemversion zu sehen.

Was verursacht das? Warum bewertet Path seine Maschine nicht mit dem neuen JAVA_HOME neu, wenn mein Rechner es tut?

(Ist es, weil es nicht das Erste ist, was auf dem Weg ist? Wenn ja, wie könnte das sein und warum?) Ich würde mehr Tests machen, um zu überprüfen, aber ich denke, er hat es satt und möchte gerne wieder arbeiten .)

38
Für alle, die sich dafür entschieden haben, zu schließen (3 im Moment) ... wenn irgendwo ein Dup ist, wäre ein Kommentar, der mich darauf hinweist, sicher nett. Wenn es kein Dummkopf ist ... dann wäre es auch nett, mir zu sagen, was Sie mit dieser Frage falsch finden. skiphoppy vor 14 Jahren 6
Vielleicht, weil es sich eher um eine Systemfrage als um eine Programmierfrage handelt, obwohl sie direkte Auswirkungen auf die Programmierung hat, deshalb stimme ich nicht dafür, sie zu schließen ... :) vor 14 Jahren 1
Attenion close-nazis: Ich möchte die Ansicht vertreten, dass eine Frage zu Stack Overflow vor dem Eintreffen von superuser.com und serverfault.com vor dem Eintreffen von superuser.com angemessen war. Dies ist eine Programmierfrage. skiphoppy vor 14 Jahren 6
Do you mean that programmers are only users of Windows, who may have this problem? Shut up you, programmer-nazi! Secondly, before more appropriate Q&A site arrived, you had no option to post question here. The hospitality of SO must be not an argument for abusing it. Val vor 10 Jahren 0
Ich betrachte dies in Windows 10 - die Variablensubstitution in PATH schlug fehl, _intermittent_ zu funktionieren. Das Aufrufen von Umgebungsvariablen und das Speichern (ohne Änderung) und das Öffnen einer neuen CMD-Eingabeaufforderung löste das Problem. Thomas W vor 7 Jahren 0

13 Antworten auf die Frage

34
JPaget

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

Vielleicht wird dies durch ein vereinfachtes Beispiel klarer. Angenommen, die Systemumgebung ist

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

und die Umgebung von User 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.

Mein System hatte einige Benutzer-Umgebungsvariablen mit demselben Namen wie einige System-Umgebungsvariablen. Echoing PATH würde sie nicht erweitern - nachdem ich dies gelesen hatte, entfernte ich die doppelten Benutzervariablen, da ich mich fragte, ob sie mit Vorrang aufgenommen wurden (aber nicht erweitert werden konnten). Das hat jetzt für mich funktioniert - vielen Dank. :) Michael vor 9 Jahren 2
Gibt es eine Möglichkeit über Powershell, den ursprünglichen, nicht ausgedehnten PFAD zu erhalten? Ich hatte gehofft, an meinen PATH anzuhängen und dabei die nicht erweiterten Umgebungsvariablen zu erhalten. CMCDragonkai vor 7 Jahren 0
Mit etwas Hilfe aus einer anderen Frage gelöst. Schreiben Sie dazu ein Powershell-Skript: https://gist.github.com/CMCDragonkai/a02d77c2d7c0799dd42fd2aab26a3cd5 CMCDragonkai vor 7 Jahren 0
13
climenole

Ü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 angegeben. Geben Sie den Typ REG_EXPAND_SZ mit der reg add /t REG_EXPAND_SZOption an.

yep ... das ist eine dieser Einstellungen, die ich immer zu vergessen scheint ... pesky Registry ;-) Eddie B vor 10 Jahren 0
9
RobDavenport

Es gibt ein eindeutiges Problem beim Erweitern von Umgebungsvariablen innerhalb der PATH-Variablen, wenn die Variable zu einem Pfad erweitert wird, der Leerzeichen enthält.

Wir haben unsere eigenen Systemebenenvariablen wie "OUR_ROOT = c: \ MyRoot" erstellt und dann im System PATH wie "PATH =;% OUR_ROOT% \ bin;" und das wird korrekt zu "PATH =; c: \ MyRoot \ bin;" erweitert. Bisher kein Problem.

Aber unter Windows 7 (32-Bit) habe ich ein Produkt selbst installieren lassen und Systemumgebungsvariablen wie folgt erstellen:

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

und fügte es der Systemvariable PATH 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, die eine DLL in diesem Verzeichnis benötigten.

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

STUDIO_BIN=C:\ProductName\bin

und dann das CMD-Fenster neu starten, ist der PFAD jetzt:

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

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

STUDIO_BIN=C:\Program Files\Company Name

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

Seltsamerweise, wenn ich wieder hineinging und "Product Name 10.4" zu STUDIO_BIN hinzufügte (einschließlich aller Leerzeichen, die vor dem Mucken vorhanden waren) und PATH noch STANDARD richtig erweitert wurde.

Offensichtlich wird die PATH-Variable mit genügend Änderungen am Inhalt im Dialogfeld "Umgebungsvariablen" einer zusätzlichen Verarbeitung unterzogen, damit sie funktionieren kann. Die Verarbeitung wird nicht durchgeführt, wenn die Variable vom Installationsprogramm des Produkts hinzugefügt wurde (was wahrscheinlich nur PATH direkt in der Registrierung geändert hat).

Ich bin fast sicher, das war auch ein Problem mit XP. In Windows 7 ist es gerade wieder aufgetaucht, als ich eine neue Entwicklungsmaschine zusammengestellt habe. Anscheinend wurde es nicht von Microsoft behoben.

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

Diese Seite bietet eine mögliche Antwort, wenn Sie PATH über die Befehlszeile oder die Batchdatei einstellen. (Schließen Sie den gesamten Befehl hinter SET in Anführungszeichen ein.) Ich weiß nicht, mit welchem ​​Installationsprogramm das von mir installierte Produkt die Umgebungsvariablen festlegte, aber es ging offensichtlich um die Verarbeitung, die erforderlich ist, um die Pfade ordnungsgemäß mit Leerzeichen zu erweitern.

Zusammenfassend können Sie also:

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

  • Bearbeiten Sie die Variablen, die nicht im Dialogfeld "Umgebungsvariablen" erweitert werden können (ändern Sie sie so, dass sie korrekt verarbeitet werden können. Ich bin nicht sicher, wie viel ausreicht).

7
Ian Boyd

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

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

Ich versuche, einen Ordner zur Umgebungsvariable Path des Systems hinzuzufügen.

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

zur vorhandenen Pfadvariablen:

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, wo Sie es bearbeiten:

alt text

Und ich füge meine Variable dem Pfad hinzu:

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

Beim Öffnen eines neuen Eingabeaufforderungsfensters wird die Umgebungsvariable nicht durch ihren tatsächlichen Wert ersetzt:

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

Was Sie in dem folgenden Screenshot sehen können:

alt text

Aber um deine Frage zu beantworten: Ich weiß es nicht. Scheint, als wäre es nicht möglich.

5
Sekhat

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

2
Nij

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

2
Justin

Add the environment variables whilst logged onto the /console session using MSTSC.

Reboot the machine and you will find your environment variables will have persisted.

There appears to be a quirk in the O/S depending on how you were connected to the machine when you attempted to change the environment variable.

1
libjack

Es kann sich auf die Funktion "verzögerte Umgebungsvariablenerweiterung" beziehen (oder deren Fehlen), oder Sie können diese Funktion nutzen, um immer eine korrekte Lösung zu erhalten.

von einer cmd-Eingabeaufforderung

set /?

und lesen Sie den Abschnitt, der "verzögerte Umgebungsvariablenerweiterung" beschreibt, 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 Echoleitung nicht erhalten, könnte das die Erklärung erklären ...

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

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

Für mich (läuft unter XP) hat das 1. Skript nicht funktioniert, aber die zweite Version (mit cmd.exe / V)

1
BAP

Ich hatte das gleiche Problem, und ich weiß, wie ich es reparieren kann.

Bearbeiten Sie einfach Ihren PATH erneut, nehmen Sie jedoch keine Änderungen vor und speichern Sie PATH erneut. Aus irgendeinem Grund werden alle verschachtelten Umgebungsvariablenreferenzen erneut bewertet.

Wenn es nicht funktioniert, machen Sie es ein paar Mal mehr, irgendwie klappt es einfach von selbst.

1
user539484

I do believe what Windows fails to expand a variable in PATH because it thinks what it not defined yet. Consider:

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

This hypothesis conforms with my other observation - adding %ProgramFiles%\Something to the users PATH will always result in expected expansion of %ProgramFiles%, given it has been defined in machine environment at the time of variable change notification (due loading order - MACHINE and then USER). But when you modify machine environment correct variable expansion only happens at the boot time (right now I have no idea how and why this not happens on the regular basis).

Verwandte Probleme