Eseguibili in-path non trovati quando chiamati dalla console "Apri finestra di comando qui"

Io uso diversi strumenti CLI come curl, ipcalc, perl, php, wget, eccetera.

Quando apri un prompt dei comandi tramite il menu Start o "Esegui ..." & gt; cmd Posso invocare questi strumenti semplicemente dando il loro nome:

Microsoft Windows [version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\cduv>wget
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.

C:\Users\cduv>php
^C

Ma ho notato che quando si utilizza un prompt dei comandi aperto tramite la finestra nativa "Apri finestra di comando qui" del menu contestuale SHIFT-down non funziona.

Microsoft Windows [version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\cduv>wget
'wget' not recognized as an internal or external command,
operable program or batch file.

C:\Users\cduv>php
'php' not recognized as an internal or external command,
operable program or batch file.

La variabile d'ambiente PATH sembra OK (altrimenti non potrei eseguire gli eseguibili come mostrato nel primo esempio).

C'è una spiegazione a tale differenza? Come posso risolvere la console "Apri la finestra di comando qui"?

(Sto usando Windows 7)

MODIFICARE:

% PATH% contenuto sulla console standard:

C:\Users\cduv>echo %PATH%
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\ActivePerl 5.14.2.1402\site\bin;C:\Program Files\ActivePerl 5.14.2.1402\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\PHP 5.5.5\ext;C:\Program Files (x86)\PHP 5.5.5;C:\Program Files (x86)\PsTools 2.44;C:\Program Files (x86)\wget 1.11.4;C:\Program Files\cURL 7.23.1;C:\Program Files\TortoiseGit 1.7.15.0\bin;C:\Drivers\AMD Catalyst Suite 13.1\ATI.ACE\Core-Static;C:\Program Files\Slik Subversion 1.8.3-1\bin

% PATH% contenuto nella console "Apri finestra di comando qui":

C:\>echo %PATH%
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\ActivePerl 5.14.2.1402\site\bin;C:\Program Files\ActivePerl 5.14.2.1402\bin;%CommonProgramFiles%\Microsoft Shared\Windows Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;%ProgramFiles(x86)%\PHP 5.5.5\ext;%ProgramFiles(x86)%\PHP 5.5.5;%ProgramFiles(x86)%\PsTools 2.44;%ProgramFiles(x86)%\wget 1.11.4;%ProgramFiles%\cURL 7.23.1;%ProgramFiles%\TortoiseGit 1.7.15.0\bin;C:\Drivers\AMD Catalyst Suite 13.1\ATI.ACE\Core-Static;%ProgramFiles%\Slik Subversion 1.8.3-1\bin

Usando Process Explorer (da Sysinternals) posso dire quale riga di comando è stata usata per aprire il prompt dei comandi

Tramite il menu Start o Esegui prompt: "C:\Windows\system32\cmd.exe"

(Albero principale: explorer.exe & gt; cmd.exe)
Tramite "Apri finestra di comando qui": "cmd.exe" /s /k pushd "C:\"

(Albero principale: wininit.exe & gt; services.exe & gt; svchost.exe & gt; explorer.exe & gt; cmd.exe)

windows command-line path

— CDuv
fonte

qual è l'output di 'echo% path%' nella finestra di cmd aperta qui?

— Gotschi

Posso confermare che gli exes sul mio% PATH% non sono influenzati da come apro il prompt dei comandi. Posso eseguirli senza problemi, entrambi da run -> cmd.exe e da open Command prompt here.

— Frank Thomas

Se wget & Amp; c. non sono in nessuna directory che è un membro del tuo percorso, come stai eseguendo anche nel caso di successo? Metti in questo modo: se non modifichi la tua domanda per mostrare l'output di echo %PATH% per le shell iniziate in entrambe le direzioni, nessuno che cerchi di rispondere alla tua domanda sarà in grado di superare il pensiero "Bene, i percorsi devono essere diversi in qualche modo ... ", quindi aggiungere queste informazioni aumenta notevolmente le possibilità di ottenere una risposta utile, senza alcun inconveniente corrispondente. Può anche andare avanti e farlo, non credi?

— Aaron Miller

Ho aggiunto entrambi% PATH% come suggerito correttamente. Se li confrontiamo sembrano quasi la stessa eccetto la "Open command window here" visualizza le variabili di ambiente come tali e non il loro valore ((id. %ProgramFiles(x86)% invece di C:\Program Files (x86) come nella console standard (funzionante)).

— CDuv

@CDuv La "finestra di comando di apertura qui" versione non espandendo le variabili di ambiente sembra piuttosto probabile che sia alla radice del problema. Non so davvero cosa si possa fare a riguardo, ma questa domanda Super User e le sue risposte sembrano essere un buon punto di partenza.

— Aaron Miller