Pourquoi Windows ne peut-il pas gérer une variable d'environnement dans Path ?

Ajoutez les variables d'environnement lorsque vous êtes connecté à la session /console à l'aide de MSTSC.

Redémarrez la machine et vous constaterez que vos variables d'environnement ont été conservées.

Il semble qu'il y ait une bizarrerie dans le système d'exploitation en fonction de la façon dont vous étiez connecté à la machine lorsque vous avez tenté de modifier la variable d'environnement.

Cela peut être lié à la fonction "expansion retardée des variables d'environnement" (ou à l'absence de cette fonction), ou peut-être pouvez-vous tirer parti de cette fonction pour toujours avoir une solution correcte.

à partir d'une invite cmd

set /? 

et lisez la section décrivant "l'expansion retardée des variables d'environnement", qui inclut un petit exemple pour tester

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

Si vous n'obtenez pas la ligne d'écho, cela pourrait expliquer la situation...

Cependant, si vous démarrez cmd.exe avec l'option /V, vous pouvez utiliser " !" au lieu de "%", ce qui modifie l'apparence.

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

Pour moi (sous XP), le 1er script n'a pas fonctionné, mais la seconde version a fonctionné (avec cmd.exe /V)

J'ai eu le même problème, et je sais comment le résoudre, c'est nul.

Il suffit d'éditer à nouveau votre PATH, sans rien changer, et de réenregistrer PATH. Pour une raison quelconque, cela entraîne la réévaluation de toutes les références aux variables d'environnement imbriquées.

Si cela ne fonctionne pas, recommencez plusieurs fois, vous verrez que cela s'arrangera tout seul.

Je pense que Windows ne parvient pas à développer une variable dans PATH parce qu'il pense qu'elle n'est pas encore définie. Considérez :

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

Cette hypothèse est conforme à mon autre observation - l'ajout de %ProgramFiles%\Something à la utilisateurs PATH se traduira toujours par une expansion attendue de %ProgramFiles% si elle a été définie dans l'environnement de la machine au moment de la notification du changement de variable (ordre de chargement - MACHINE puis UTILISATEUR). Mais lorsque vous modifiez l'environnement de la machine, l'expansion correcte de la variable ne se produit qu'au moment du démarrage (pour l'instant, je n'en ai aucune idée). comment et pourquoi cela ne se produit pas régulièrement).

Peut-être vous y prenez-vous mal ?

J'ai essayé avec Windows XP Pro SP3 (32bit). J'ai un chemin avec plusieurs occurrences de %JAVA_HOME% (et %JAVAFX_HOME% etc.) Je vais en ligne de commande, je tape PATH Je vois que les variables sont élargies. C'est bien.

Je modifie la valeur de JAVA_HOME . Retour à la même fenêtre de ligne de commande, PATH encore une fois, même valeur... comme prévu (par expérience !).

J'ouvre une nouvelle fenêtre de ligne de commande, je tape PATH Je vois la nouvelle valeur.

Je ne suis pas sûr du mécanisme exact, mais il semble que tout programme en cours d'exécution, y compris cmd.exe, capture les valeurs des variables d'environnement au moment du démarrage, et ne revient pas en arrière... (bien que je pense qu'un programme qui se comporte bien peut écouter les changements d'environnement, mais je n'en suis pas sûr).

Cela peut être considéré comme une caractéristique, un bogue ou une gêne, mais c'est ainsi que cela fonctionne. Au moins, contrairement à Win9X, il n'est pas nécessaire de redémarrer l'ordinateur ! Et contrairement à l'époque NT (IIRC), il n'est pas nécessaire de se déconnecter et de revenir.

Pourquoi cette incohérence ? Les voies de Microsoft sont impénétrables... :-P