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

Vérifier 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 est défini comme un REG_EXPAND_SZ valeur.

Si vous utilisez reg.exe via la ligne de commande pour ajouter/modifier des valeurs de registre, le type REG_SZ est utilisé par défaut. Spécifiez le type REG_EXPAND_SZ en utilisant l'option reg add /t REG_EXPAND_SZ option.

L'expansion des variables d'environnement dans la variable PATH pose un problème certain lorsque la variable s'étend à un chemin d'accès contenant des espaces.

Nous avons créé nos propres variables au niveau du système comme "OUR_ROOT=c : \MyRoot et l'utiliser ensuite dans le PATH du système comme "PATH=;%OUR_ROOT%". \bin ;" et cela se développe correctement en "PATH=;c : \MyRoot\bin ;". Jusqu'à présent, aucun problème.

Mais, sous Windows 7 (32 bits), j'ai eu un produit qui s'est installé tout seul et qui a créé des variables d'environnement système comme ceci :

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

et il l'a ajouté à la variable PATH du système :

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 n'a pas été développée non plus. Cela signifie que je ne pouvais pas exécuter de programmes nécessitant une DLL dans ce répertoire.

En changeant STUDIO_BIN (via Poste de travail>Propriétés>Avancé ...>Vars d'environnement) pour un nom sans espaces intégré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 à modifier suffisamment la variable système que vous utilisez dans le PATH à l'aide de 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 j'ai validé, démarré une nouvelle invite CMD et le PATH n'a PAS été correctement développé. J'ai ensuite essayé de supprimer partie de la voie pour qu'elle soit

STUDIO_BIN=C:\Program Files\Company Name

(en omettant "Product Name 10.4") et voilà que l'invite CMD suivante affiche PATH avec STUDIO_BIN correctement développé !

Curieusement, si j'y retourne et que j'ajoute le "Nom du produit 10.4" à STUDIO_BIN (y compris tous les espaces qui s'y trouvaient à l'origine avant que je ne commence à le manipuler), le PATH est TOUJOURS correctement développé.

Il est évident qu'en modifiant suffisamment son contenu, la variable PATH subit un traitement supplémentaire dans la boîte de dialogue Variables d'environnement, ce qui lui permet de fonctionner. Ce traitement n'a pas été effectué lorsque la variable a été ajoutée par le programme d'installation du produit (qui a probablement modifié PATH directement dans le registre).

Je suis presque certain qu'il s'agissait d'un problème avec XP également. Il vient de refaire surface pour moi dans Windows 7 alors que j'étais en train d'assembler une nouvelle machine de développement. Apparemment, ce problème n'a pas été résolu par Microsoft.

Apparemment, même les variables définies par MS comme %ProgramFiles% ne se développent pas correctement dans le PATH.

Cette page fournit une réponse possible si vous définissez PATH via la ligne de commande ou un fichier batch. (Je ne sais pas quel programme d'installation a été utilisé pour définir les variables d'environnement, mais il a manifestement contourné le traitement nécessaire pour étendre correctement les chemins d'accès avec des espaces.

Ainsi, pour résumer, vous pouvez soit

• modifier les chemins d'accès (et déplacer tous les fichiers associés) en chemins d'accès sans espaces, ou

• modifiez les variables qui ne se développent pas dans la boîte de dialogue Variables d'environnement (modifiez-les suffisamment pour qu'elles soient traitées correctement - je ne suis pas certain de savoir ce qui est suffisant).

Il existe deux niveaux de variables d'environnement, global et utilisateur. S'il a défini %Java_home% comme variable d'environnement utilisateur, mais qu'il modifie la variable globale, il ne verra aucune différence.

Il faut tenir compte de l'ordre dans lequel les variables sont définies lors de la connexion. Si vous essayez d'utiliser une variable avant qu'elle ne soit définie, vous obtiendrez une chaîne vide.

Le PATH effectif est la concaténation de la variable PATH de l'utilisateur suivie de la variable PATH globale.

Les variables utilisateur sont définies avant les variables globales, de sorte que vous ne pouvez pas utiliser de variables globales dans votre variable PATH utilisateur. De plus, les variables sont définies dans l'ordre alphabétique, vous ne pouvez donc pas utiliser les variables qui sont classées avant PATH.

(Cela s'applique au moins à Windows 7. Je ne l'ai pas testé sur des versions plus récentes).

Assurez-vous qu'il n'y a pas d'espace dans le 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 " ;" et ". C:\GNAT\include ".