Czy wiersz polecenia systemu Windows szuka innego miejsca niż te określone przez zmienną PATH podczas uruchamiania aplikacji?

Próbowałem następującego eksperymentu.

Przed rozpoczęciem sprawdziłem zmienną PATH z cmd, która ma następującą wartość:

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\;

Na początku myślałem, że cmd szuka tylko plików wykonywalnych w katalogach zawartych w zmiennej PATH, więc losowo wybrałem aplikację - winword.exe (Microsoft Word) i próbowałem uruchomić ją z wiersza poleceń:

start winword

Ale ku mojemu zaskoczeniu program uruchamia się! Jestem zaskoczony, ponieważ przeszukałem wszystkie katalogi w zmiennej PATH w poszukiwaniu pliku exe o nazwie „winword”, ale wszystkie moje wyszukiwania były puste!

Doszedłem zatem do wniosku, że wiersz polecenia musiał znać wyszukiwanie w miejscach innych niż te określone w zmiennej PATH, aby szukać plików wykonywalnych.

Oczywiście następną rzeczą, jaką zrobiłem, było poszukiwanie dokładnej lokalizacji, w której znajduje się plik wykonywalny „winword”. Okazuje się, że winword.exe znajduje się tutaj:

C:\Program Files\Microsoft Office 15\root\office15

Stąd pomysł, że CMD może automatycznie przeglądać ProgramFiles i ProgramFiles (x86) (i wszystkie ich podkatalogi) podczas wykonywania polecenia „start”? Co skłoniło mnie do próby uruchomienia innej aplikacji zainstalowanej na moim komputerze, Audacity, z plikiem exe znajdującym się pod adresem:

C:\Program Files (x86)\Audacity

Ponownie, ku mojemu zaskoczeniu, Audacity nie uruchomiło się podczas pisania:

start audacity

w wierszu poleceń.

Następnie dodałem katalog zawierający audacity.exe do PATH:

set path=%path%;C:\Program Files (x86)\Audacity

po czym spróbowałem ponownie uruchomić audacity:

start audacity

Nic dziwnego, że uruchomiono Audacity.

Chcę wiedzieć, gdzie dokładnie wiersz polecenia szuka plików wykonywalnych? Dlaczego program winword.exe uruchamia się nawet wtedy, gdy katalog go zawierający nie jest częścią ŚCIEŻKI, ale to samo nie jest prawdą w przypadku audacity.exe?

Próbowałem też innych aplikacji. Chrome i Firefox działają, gdy używam polecenia start.

AKTUALIZACJA: Korzystam z systemu Windows w wersji 6.3.9600 (Windows 8.1)

Na początku myślałem, że cmd szuka tylko plików wykonywalnych w katalogach zawartych w zmiennej PATH, więc losowo wybrałem aplikację - winword.exe (Microsoft Word) i próbowałem uruchomić ją z wiersza poleceń:

Powodem winword.exetego jest fakt, że istnieje klucz rejestru, który definiuje ścieżkę do Microsoft Word (Winword.exe). Podobny klucz istnieje dla programów Firefox.exe i Chrome.exe, jeśli te aplikacje są zainstalowane.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

Chcę wiedzieć, gdzie dokładnie wiersz polecenia szuka plików wykonywalnych?

Zmienna systemowa PATH, zmienna PATH użytkownika i różne klucze ..\App Paths. Udało mi się potwierdzić, że Audacity nie tworzy dla siebie klucza po zainstalowaniu.

Gdy funkcja ShellExecuteEx jest wywoływana z nazwą pliku wykonywalnego w parametrze lpFile, istnieje kilka miejsc, w których funkcja szuka pliku. Zalecamy zarejestrowanie aplikacji w podkluczu rejestru Ścieżki aplikacji. Pozwala to uniknąć potrzeby modyfikowania systemowej zmiennej środowiskowej PATH przez aplikacje.

• Bieżący katalog roboczy.
• Tylko katalog Windows (nie są przeszukiwane żadne podkatalogi).
• Katalog Windows \ System32.
• Katalogi wymienione w zmiennej środowiskowej PATH.
• Zalecane: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ App Paths

Źródło: Rejestracja aplikacji

W wierszu polecenia, jeśli WinWordgo wpiszesz , nie uruchomi się.

Jeśli wpiszesz START WinWord, uruchomi się.

StartPolecenia jest tutaj kluczem.

Podczas próby uruchomienia pliku za pomocą polecenia Start Wiersz polecenia nie wykonuje żadnego wyszukiwania. Zamiast tego przekazuje nazwę pliku (i argumenty) do samego systemu Windows (za pośrednictwem wywołania API ShellExecuteEx), który musi następnie wyszukać lokalizację pliku. Jest kilka miejsc, które wyszukuje w następującej kolejności:

• Bieżący katalog roboczy.

• Tylko Windowskatalog (nie są przeszukiwane żadne podkatalogi).

• Windows\System32Katalogiem.

• Katalogi wymienione w PATHzmiennej środowiskowej.

• Zalecana:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

WinWordjest w tym kluczu rejestru. Kluczem jest powstrzymanie się PATHprzed zbyt długim czasem.

Program (po określeniu nazwy modułu bez napędu / ścieżki w wierszu polecenia) w procesorze poleceń systemu Windows (CMD.EXE) można uruchomić, gdy zostanie znaleziony:

• według zmiennej środowiskowej PATH (zarówno plik wykonywalny, jak i jego hardlink / softlink / skrót o tej samej nazwie)

• przez alias DOSKEY

• według ścieżki aplikacji z HKLM\Software\Microsoft\Windows\CurrentVersion\App Pathslub HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths(przy użyciu startpolecenia)

Korzystając z tej wiedzy (zwłaszcza ostatniej), możesz stworzyć własne aliasy, które są dla Ciebie wygodne. Na przykład możesz utworzyć HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\au.exez domyślną wartością C:\Program Files (x86)\Audacity\Audacity.exei uruchomić tę aplikację, po prostu wpisując start auwiersz polecenia.

Podczas gdy inne odpowiedzi mogą być konkretnym powodem w twoim przypadku, istnieje również inna odpowiedź na twoje pytanie, która mogła mieć miejsce w przypadku niektórych innych aplikacji: w tym samym miejscu, w którym szukałeś, ale z różnymi rozszerzeniami plików.

W szczególności powiedziałeś, że szukasz plików z rozszerzeniem exe. Windows podejmie również próbę wykonania plików innych rozszerzeń.

Inną zmienną środowiskową, która wchodzi w grę podczas wykonywania polecenia, jest zmienna PATHEXT. To jest ;-delimitowana lista rozszerzeń plików, które należy wykonać. Jeśli echo, PATHEXTmożesz zobaczyć coś takiego .COM;.EXE;.BAT;.CMD;.VBS;... (itp.). Niektóre aplikacje używają tych innych typów plików jako punktu wejścia użytkownika końcowego. Jest znacznie mniej powszechny, ale się zdarza. Użyłem kilku głównych produktów komercyjnych, które zaczynają się od .BATskryptów. Aby użyć jednego z nich jako przykładu, mogę uruchomić go poleceniem, standalonenawet jeśli nie ma standalone.exe... zamiast tego ma on standalone.bat.

Niektóre rozszerzenia, które PATHEXTmam na teraz patrzę, nigdy nie miałem zastosowania aplikacji. Te, które ja nie napotkasz wiele częściej (ale oczywiście nie tak bardzo jak exe) to: .com, .bat, .vbs, .js, .jar. Pierwsze dwa to pliki skryptów wsadowych systemu Windows, a pozostałe trzy to typy plików dla określonych języków programowania, które są uruchamiane ze skryptów lub maszyn wirtualnych zamiast ze exes (odpowiednio: Visual Basic, JavaScript i Java).

start winwordnie mówi wiersza polecenia, aby uruchomić winword. Mówi wierszowi poleceń, aby uruchomić startz argumentem winword. Startkorzysta z własnych metod wyszukiwania winword.

Po prostu winwordmówi wiersz polecenia, aby uruchomić winword. A jeśli spróbujesz, ponieważ winwordnie PATHma go, nie uruchamia się.