L'invite de commande Windows recherche-t-elle ailleurs que dans les emplacements spécifiés par la variable PATH lors du lancement de programmes d'application?
J'ai essayé l'expérience suivante.
Avant de commencer, j’ai vérifié la variable PATH de cmd, qui a la valeur suivante:
Path=C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\ProgramData\Lenovo\ReadyApps;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\Skype\Phone\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Calibre2\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;
Au début, je pensais que cmd ne cherchait que les exécutables dans les répertoires contenus dans la variable PATH. J'ai donc choisi au hasard une application - winword.exe (Microsoft Word) et essayé de le lancer à partir de la ligne de commande:
start winword
Mais à ma grande surprise, le programme est lancé! La raison pour laquelle je suis surpris, c'est parce que j'ai cherché dans tous les répertoires de la variable PATH le fichier exe appelé 'winword', mais que toutes mes recherches sont vides!
J'ai donc conclu que la commande Invite devait savoir qu'il fallait rechercher dans des emplacements autres que ceux spécifiés dans la variable PATH pour rechercher les exécutables.
Alors évidemment, la prochaine chose que j'ai faite a été de rechercher l'emplacement précis du fichier exécutable 'winword'. Il s'avère que winword.exe se trouve ici:
C:\Program Files\Microsoft Office 15\root\office15
Par conséquent, cela me donne l’idée que CMD consulte automatiquement ProgramFiles et ProgramFiles (x86) (et tous leurs sous-répertoires) lors de l’exécution de la commande 'start'? Ce qui m'a amené à lancer une autre application installée sur mon ordinateur, Audacity, avec le fichier exe situé à l'adresse:
C:\Program Files (x86)\Audacity
Encore une fois, à ma grande surprise, Audacity n’a pas été lancé lorsque j’ai tapé:
start audacity
à la ligne de commande.
J'ai ensuite ajouté le répertoire contenant audacity.exe à PATH:
set path=%path%;C:\Program Files (x86)\Audacity
après quoi j'ai essayé de lancer à nouveau l'audace:
start audacity
Eh bien, sans surprise, Audacity a lancé.
Ce que je veux savoir, c’est où exactement la commande Invite recherche les exécutables? Pourquoi est-ce que winword.exe se lance même lorsque le répertoire qui le contient ne fait pas partie de PATH, mais que ce n’est pas le cas pour audacity.exe?
J'ai aussi essayé d'autres applications. Chrome et Firefox fonctionnent lorsque j'utilise la commande de démarrage.
UPDATE: J'utilise Windows version 6.3.9600 (Windows 8.1)
Au début, je pensais que cmd ne cherchait que les exécutables dans les répertoires contenus dans la variable PATH. J'ai donc choisi au hasard une application - winword.exe (Microsoft Word) et essayé de la lancer à partir de la ligne de commande:
La raison pour laquelle winword.exe a fonctionné est qu’il existe une clé de registre définissant le chemin d’accès à Microsoft Word (Winword.exe). Une clé similaire existe pour Firefox.exe et Chrome.exe si ces applications sont installées.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App PathsHKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Ce que je veux savoir, c’est où exactement la commande Invite recherche les exécutables?
Variable PATH système, variable PATH utilisateur et les différentes clés contenues dans ..\App Paths. J'ai pu confirmer qu'Audacity ne crée pas de clé lorsqu'il est installé.
Lorsque la fonction ShellExecuteEx est appelée avec le nom d'un fichier exécutable dans son paramètre lpFile, la fonction recherche le fichier à plusieurs endroits. Nous vous recommandons d'enregistrer votre application dans la sous-clé de registre App Paths. Cela évite aux applications de devoir modifier la variable d’environnement PATH du système.
- Le répertoire de travail actuel.
- Le répertoire Windows uniquement (aucun sous-répertoire n'est recherché).
- Le répertoire Windows\System32.
- Répertoires répertoriés dans la variable d’environnement PATH.
- Recommandé: chemins d'accès HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Source: Enregistrement de l'application
A partir de la commande Invite, si vous entrez simplement WinWord, l'exécution échoue.
Si vous entrez START WinWord, il est exécuté.
La commande Start est la clé ici.
Lorsque vous essayez d'exécuter un fichier à l'aide de la commande de démarrage, l'invite de commande n'effectue aucune recherche. Au lieu de cela, il transmet le nom du fichier (et les arguments) à Windows lui-même (via l'appel de l'API ShellExecuteEx), qui doit ensuite rechercher l'emplacement du fichier. La recherche s'effectue dans plusieurs endroits dans l'ordre suivant:
Le répertoire de travail actuel.
Le répertoire
Windowsuniquement (aucun sous-répertoire n’est recherché).Le répertoire
Windows\System32.Répertoires répertoriés dans la variable d'environnement
PATH.Conseillé:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
WinWord est dans cette clé de registre. La clé est là pour éviter que PATH ne soit trop long.
Le programme (lorsque vous spécifiez son nom de module sans lecteur/chemin d'accès dans l'invite de commande) dans le processeur de commandes Windows (CMD.EXE) peut être démarré s'il est trouvé:
par la variable d’environnement PATH (le fichier exécutable et son lien physique/lien physique/raccourci du même nom)
par alias DOSKEY
par chemin d'application à partir de
HKLM\Software\Microsoft\Windows\CurrentVersion\App PathsouHKCU\Software\Microsoft\Windows\CurrentVersion\App Paths(lors de l'utilisation de la commandestart)
En utilisant cette connaissance (en particulier la dernière), vous pouvez créer vos propres alias qui vous conviennent. Par exemple, vous pouvez créer HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\au.exe avec la valeur par défaut C:\Program Files (x86)\Audacity\Audacity.exe et démarrer cette application en tapant simplement start au dans la commande Invite.
start winword n'indique pas à la commande Invite de lancer winword. Il indique à la commande Invite de lancer start avec l'argument winword. Start utilise ses propres méthodes pour trouver winword.
Juste winword indique à la commande Invite de lancer winword. Et si vous essayez cela, puisque winword ne figure pas sur la PATH, elle ne se lancera pas.
Bien que les autres réponses soient probablement la raison spécifique de votre cas, il existe également une autre réponse à votre question qui aurait pu être le cas pour d'autres applications: au même endroit que vous cherchiez, mais avec des extensions de fichier différentes.
Vous avez spécifiquement indiqué que vous recherchiez des fichiers d’extension exe. Windows tentera également d'exécuter des fichiers d'autres extensions.
Une autre variable d'environnement qui entre en jeu lors de l'exécution d'une commande est la variable PATHEXT. Il s'agit d'une liste délimitée par ;- des extensions de fichier à tenter de s'exécuter. Si vous faites écho à PATHEXT, vous verrez peut-être quelque chose comme .COM;.EXE;.BAT;.CMD;.VBS;... (etc.). Certaines applications utilisent ces autres types de fichiers comme point d’entrée pour l’utilisateur final. C'est beaucoup moins courant, mais ça arrive. J'ai utilisé plusieurs produits commerciaux majeurs qui partent de scripts .BAT. Pour utiliser l'un d'eux à titre d'exemple, je peux le démarrer avec la commande standalone même s'il n'y a pas de standalone.exe... à la place, il a un standalone.bat.
Certaines des extensions que j'ai sur la PATHEXT que je suis en train de regarder ne se sont jamais utilisées. Ceux que je ai rencontrés sont beaucoup plus souvent rencontrés (mais évidemment pas autant que exe) sont: .com, .bat, .vbs, .js, .jar. Les deux premiers sont des fichiers de script batch Windows et les trois autres types de fichiers de langages de programmation spécifiques exécutés à partir de scripts ou de machines virtuelles au lieu de exes (respectivement: visual basic, javascript et Java).