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 parcouru tous les répertoires de la variable PATH pour le fichier exe appelé 'winword' mais que toutes mes recherches sont vides!

J'ai donc conclu que l'invite de commande 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

Donne-moi donc 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 à quel endroit l'invite de commande cherche-t-elle exactement 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 a winword.exefonctionné 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 Paths HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

Ce que je veux savoir, c'est à quel endroit l'invite de commande cherche-t-elle exactement les exécutables?

Variable système PATH, variable utilisateur PATH et les différentes clés qu’elle contient ..\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

À partir de l'invite de commande, si vous entrez simplement, WinWordson exécution échoue.

Si vous entrez, START WinWordça fonctionne.

La Startcommande 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 Windowsrépertoire uniquement (aucun sous-répertoire n'est recherché).

• Le Windows\System32répertoire.

• Répertoires répertoriés dans la PATHvariable d'environnement.

• Conseillé:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

WinWordest dans cette clé de registre. La clé est là pour éviter PATHde prendre trop de temps.

Le programme (lorsque vous indiquez 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 depuis HKLM\Software\Microsoft\Windows\CurrentVersion\App Pathsou HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths(lors de l'utilisation de la startcommande)

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.exeavec la valeur par défaut de C:\Program Files (x86)\Audacity\Audacity.exeet démarrer cette application en tapant simplement start audans l'invite de commande.

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 avec une 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. Ceci est une ;liste délimitée par les extensions de fichier à tenter de lancer. Si vous faites écho, PATHEXTvous 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 à partir de .BATscripts. Pour utiliser l' un d'entre eux comme un exemple, je peux commencer avec la commande standalonemême si il n'y a pas standalone.exe... au contraire, il a un standalone.bat.

Certaines des extensions dont je dispose PATHEXTactuellement ne sont jamais utilisées par une application. Ceux que j'ai courir dans beaucoup plus souvent (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).

start winwordn'indique pas l'invite de commande à lancer winword. Il indique à l'invite de commande de se lancer startavec un argument winword. Startutilise ses propres méthodes pour trouver winword.

Indique simplement winwordl'invite de commande à lancer winword. Et si vous essayez ça, puisque winwordn’est pas sur le PATH, il ne se lance pas.