Pourquoi Windows ne peut-il pas gérer une variable d'environnement dans Path?
Mon collègue et moi avons des postes de travail Dell identiques avec Windows XP Professional x64 edition installé.
La variable d'environnement My Path commence par:
%Java_HOME%\bin;...
La variable Path de mon collègue inclut le même répertoire, spécifié à l'aide de la même variable d'environnement, mais ce n'est pas le premier élément de son chemin.
Si j'accède aux propriétés système -> variables d'environnement et que je change la valeur de ma variable Java_HOME, la version de Java trouvée à partir de la ligne de commande change comme prévu. Ceci démarre une toute nouvelle fenêtre de console, pour être sûr de prendre en compte les modifications.
Mais sur la machine de mon collègue, ce n'est pas le cas. Il continue à retrouver sa version précédente de Java jusqu'à ce qu'il affiche sa variable Path et l'enregistre (même s'il ne la modifie pas). (Encore une fois, cela se produit lorsque vous démarrez une nouvelle fenêtre de console.)
J'observe cette incohérence sous Windows depuis environ 6 mois et je suis très curieux à ce sujet. Nous avons trop de versions de Windows dans notre bureau, j'ai donc rarement eu la chance de voir cela se produire sur deux ordinateurs exécutant exactement la même version de système d'exploitation, jusqu'à présent.
Qu'est-ce qui cause ça? Pourquoi sa machine ne réévalue-t-elle pas Path en utilisant le nouveau Java_HOME, alors que la mienne le fait?
(Est-ce parce que ce n'est pas la première chose à faire sur le chemin? Si oui, comment pourrait-il en être ainsi et pourquoi? Je ferais plus de tests pour vérifier, mais je pense qu'il en a maintenant assez et qu'il aimerait se remettre au travail .)
Votre chemin est la concaténation du chemin système suivi du chemin utilisateur. De plus, les variables d'environnement système peuvent ne pas contenir de références à des variables d'environnement utilisateur, et ces références ne seront pas développées et . Pour obtenir le résultat souhaité, insérez la référence à% Java_HOME% dans la variable d’environnement PATH de l’utilisateur ou créez-en une si elle n’existait pas encore.
Peut-être qu'un exemple simplifié le clarifiera. Supposons que l’environnement SYSTEM soit
ProgramFiles = C:\Program Files
SystemRoot = C:\WINDOWS
PATH = %SystemRoot%\SYSTEM32
et l'environnement de l'utilisateur JSmith est
Java_HOME = %ProgramFiles%\Java\bin
USERPROFILE = C:\USERS\JSmith
PATH = %Java_HOME%\bin;%USERPROFILE%\bin
alors le chemin résultant serait
C:\WINDOWS\SYSTEM32;C:\Program Files\Java\bin;C:\Users\JSmith\bin
comme voulu.
Vérifiez dans le registre Windows sous cette clé:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Environment
SI la variable d'environnement doit être développée (ici:% Java_HOME%)
alors la variable doit être définie comme une valeur REG_EXPAND_SZ .
Si vous utilisez reg.exe via la ligne de commande pour ajouter/modifier des valeurs de registre, le type par défaut est REG_SZ. Spécifiez le type REG_EXPAND_SZ en utilisant l'option reg add /t REG_EXPAND_SZ.
Il existe un problème certain avec le développement de variables d’environnement au sein de la variable PATH lorsque la variable se développe en un chemin contenant des espaces.
Nous avons créé nos propres variables de niveau système, telles que "OUR_ROOT = c:\MyRoot", puis nous l'avons utilisé dans le système PATH, tel que "PATH =;% OUR_ROOT%\bin;". et qui est étendu correctement à "PATH =; c:\MyRoot\bin;". Jusqu'à présent, pas de problème.
Mais sous Windows 7 (32 bits), un produit s’est installé et a créé des variables d’environnement système telles que celles-ci:
STUDIO_BIN=C:\program files\Company Name\Product Name 10.4\bin
et l'a ajouté à la variable système PATH:
PATH=<other path elements>;%STUDIO_BIN%;<more path elements>
Mais les valeurs PATH affichées dans CMD contenaient "% STUDIO_BIN%;" et non le chemin étendu. La valeur dans Poste de travail> Propriétés> Avancé> Env.Vars est également non développée. Cela signifiait que je ne pouvais pas exécuter de programmes nécessitant un DLL dans ce répertoire.
En changeant simplement STUDIO_BIN (via Poste de travail> Propriétés> Avancé ...> Env Vars) en un nom sans espaces incorporés:
STUDIO_BIN=C:\ProductName\bin
puis en redémarrant la fenêtre CMD, le PATH est maintenant:
PATH=<other path elements>;C:\ProductName\bin;<more path elements>
Une autre solution consiste à éditer suffisamment la variable système que vous utilisez dans PATH à l'aide de la boîte de dialogue Poste de travail> Propriétés> Avancé ...> Variables d'environnement. J'ai essayé d'ajouter un caractère et de le supprimer pour effectuer un "changement", puis de passer à OK, j'ai lancé une nouvelle invite CMD et PATH n'a PAS été correctement développé. J'ai ensuite essayé de supprimer une partie du chemin, donc c'était
STUDIO_BIN=C:\Program Files\Company Name
(en omettant "Nom du produit 10.4") et voilà, la prochaine invite CMD a montré PATH avec STUDIO_BIN correctement développé!
Bizarrement, si je suis rentré et que j'ai ajouté le "Nom du produit 10.4" à STUDIO_BIN (y compris tous les espaces qui étaient là avant que je ne commence à le faucher), PATH était toujours correctement développé.
De toute évidence, le contenu de la variable PATH ayant été suffisamment modifié, il subit un traitement supplémentaire dans la boîte de dialogue Variables d'environnement qui lui permet de fonctionner. Traitement non effectué lors de l'ajout de la variable par le programme d'installation du produit (qui vient probablement de modifier directement PATH dans le registre).
Je suis presque certain que c'était également un problème avec XP. Cela a juste refait surface pour moi dans Windows 7 alors que je construisais une nouvelle machine de développement. Apparemment, cela n’a pas été corrigé par Microsoft.
Cette page fournit une réponse possible si vous définissez PATH via la ligne de commande ou le fichier de traitement par lots. (Placez la commande entière après SET entre guillemets.) Je ne sais pas quel programme d'installation utilisé par le produit que j'ai installé permettait de définir les variables d'environnement, mais il est évident que tout le traitement nécessaire pour développer correctement les chemins d'accès avec des espaces a été pris.
Donc, pour résumer, vous pouvez soit:
changer les chemins (et déplacer tous les fichiers associés) en chemins sans espaces, ou
éditez les variables qui ne parviennent pas à se développer dans la boîte de dialogue Variables d'environnement (modifiez-les suffisamment pour les traiter correctement - je ne suis pas certain que cela suffise).
je l'ai demandé sur les forums Microsoft en mars 2009 et je ne l'ai jamais résolu:
Comment utiliser% ProgramFiles% dans la variable d’environnement Path? :
J'essaie d'ajouter un dossier à la variable d'environnement Path du système.
je veux ajouter % ProgramFiles%\SysInternals
à la variable de chemin existante:
C:\PROGRA ~ 1\Borland\Delphi5\Projets\Bpl; C:\PROGRA ~ 1\Borland\Delphi5\Bin; % SystemRoot% \system32; % SystemRoot% ;% SystemRoot %\System32\Wbem; C:\Programmes\Microsoft SQL Server\80\Tools\BINN; C:\Programmes\Microsoft SQL Server\80\Outils\Binn \; C:\Programmes\Microsoft SQL Server\90\Outils\binn \; C:\Programmes\Microsoft SQL Server\90\DTS\Binn \; C :\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE \; C:\Programmes\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies \;% SYSTEMROOT%\System32\WindowsPowerShell\v1.0 \
Donc, je vais à l'endroit où vous le modifiez:
Et j'ajoute ma variable au chemin:
% ProgramFiles %\SysInternals; C:\PROGRA ~ 1\Borland\Delphi5\Projects\Bpl; (couper)
Ensuite, en ouvrant une nouvelle fenêtre d'invite de commande, la variable d'environnement n'est pas remplacée par sa valeur réelle:
Path =% ProgramFiles %\SysInternals; C:\PROGRA ~ 1\Borland\Delphi5\Projects\Bpl (snip)>
Ce que vous pouvez voir dans la capture d'écran suivante:
Mais pour répondre à votre question: je ne sais pas. On dirait que cela ne peut pas être fait.
il existe deux niveaux de variables d'environnement, global et utilisateur. S'il a% Java_home% défini en tant que variable d'environnement utilisateur mais qu'il modifie la variable globale, il ne verra aucune différence.
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 auront persisté.
Il semble y avoir un problème dans le système d'exploitation en fonction de la manière dont vous avez été connecté à la machine lorsque vous avez tenté de modifier la variable d'environnement.
Assurez-vous qu'il n'y a pas d'espace dans PATH lorsque vous définissez vos propres variables d'environnement utilisateur. par exemple: C:\GNAT\bin; C:\GNAT\include ne fonctionnera pas, à cause de l’espace entre les ";" et "C:\GNAT\include".
J'ai eu le même problème, et je sais comment le réparer, c'est nul.
Éditez simplement votre PATH à nouveau, mais n’effectuez aucune modification et ré-enregistrez PATH. Pour une raison quelconque, toutes les références de variable d’environnement imbriquées sont réévaluées.
Si cela ne fonctionne pas, faites-le quelques fois de plus, d'une manière ou d'une autre, cela se fera tout seul.
PATH est la concaténation de la variable utilisateur PATH suivie de la variable globale PATH. Pour utiliser une variable dans une autre, la première doit déjà être définie. Les variables utilisateur sont définies avant les variables globales (du moins ici sous Windows 7 64 bits). Vous ne pouvez donc pas utiliser de variables globales dans votre variable PATH utilisateur. De plus, les variables sont définies dans l'ordre alphabétique, vous devez donc également en tenir compte.
Cela peut être lié à la fonctionnalité (ou à son absence) de "l'expansion des variables d'environnement retardées", ou vous pouvez en tirer parti pour toujours avoir une solution correcte.
à partir d'une invite de commande
set /?
et lisez la section "Développement de variables d’environnement retardées", 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 l'expliquer ...
Si, toutefois, vous démarrez votre cmd.exe avec l'option/V, vous pouvez utiliser "!" au lieu de "%", ce qui change le comportement
set VAR=before
if "%VAR%" == "before" (
set VAR=after
if "!VAR!" == "after" @echo If you see this, it worked
)
Pour moi (fonctionnant sous XP), le premier script ne fonctionnait pas, mais la deuxième version le faisait (avec cmd.exe/V)
Je crois que Windows ne parvient pas à développer une variable dans PATH car il pense ce qu’elle n’a pas encore défini. Considérer:
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 - ajouter %ProgramFiles%\Something au users PATH entraînera toujours l'extension attendue de %ProgramFiles%, étant donné qu'il a été défini dans l'environnement de la machine au moment de la notification de modification de variable (ordre de chargement variable - MACHINE, puis UTILISATEUR). Mais lorsque vous modifiez l'environnement de la machine, les variables correctes ne se développent qu'au démarrage (pour le moment, je ne sais pas du tout comment et pourquoi cela ne se produit pas régulièrement).
J'ai résolu de définir les variables d'environnement dans Système> Paramètres avancés> Variables d'environnement .
Il y a deux panneaux, les variables utilisateur et globale (l'utilisateur est votre nom d'utilisateur Windows) et les variables système sont des variables globales. Par conséquent, si vous définissez les variables "Nouveau" à partir de l'utilisateur, telles que Java_HOME et que vous définissez votre chemin, vous définissez des variables même si votre variable globale est définie. chemin ont des fichiers de programme dans le dossier.
Peut-être que vous le faites mal?
J'ai essayé avec Windows XP Pro SP3 (32 bits). J'ai un chemin avec plusieurs occurrences de %Java_HOME% (et %JAVAFX_HOME%, etc.). Je vais en ligne de commande, tapez PATH, je vois les variables développées. Bien.
Je change la valeur de Java_HOME. Retournez à la même fenêtre de ligne de commande, PATH encore, même valeur ... comme prévu (par expérience!).
J'ouvre une nouvelle fenêtre de ligne de commande, tapez PATH, gotcha, je vois la nouvelle valeur.
Je ne sais pas quel est le mécanisme exact, mais il semble que tout programme en cours, y compris cmd.exe, capture les valeurs des variables d’environnement au moment du démarrage et ne regarde pas en arrière ... (même si je crois qu'un programme bien conçu peut écoute pour les changements env, pas trop sûr cependant).
Cela peut être perçu comme une fonctionnalité, un bug ou une gêne, mais c'est ainsi que cela fonctionne. Au moins, contrairement à Win9X, nous n'avons pas à redémarrer l'ordinateur! Et contrairement à NT times (IIRC), vous n’avez pas à vous déconnecter et à revenir en arrière.
Pourquoi cette incohérence? Les voies de Microsoft sont impénétrables ... :-P