Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I uses several CLI tools such as curl, ipcalc, perl, php, wget, etc.

When opening a command prompt either via the Start menu or "Run..." > cmd I can invoke theses tools just by giving their name:

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

But I've noticed that when using a command prompt opened via the native "Open command window here" entry of the SHIFT-down contextual menu it doesn't works.

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.

PATH environment variable seems OK (otherwise I couldn't run executables as shown in the first example).

Is there an explanation to such a difference? How can I fix the "Open command window here" console?

(I'm using Windows 7)

EDIT:

%PATH% content on standard console:

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% content on "Open command window here" console:

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

By using Process Explorer (from Sysinternals) I can tell which command line were used to open command prompt

  • Via Start menu or Run prompt: "C:\Windows\system32\cmd.exe"

    (Parent tree: explorer.exe > cmd.exe)

  • Via "Open command window here": "cmd.exe" /s /k pushd "C:\"

    (Parent tree: wininit.exe > services.exe > svchost.exe > explorer.exe > cmd.exe)

share|improve this question
    
whats the output of 'echo %path%' in your open cmdwndw here? –  Gotschi Dec 11 '13 at 20:12
1  
I can confirm that exes on my %PATH% are not affected by how I open the command prompt. I can execute them with no problem, both from run -> cmd.exe and from open Command prompt here. –  Frank Thomas Dec 11 '13 at 20:18
    
If wget &c. aren't in any directory that's a member of your path, how are you executing them even in the successful case? Put it this way: If you don't edit your question to show the output of echo %PATH% for shells started both ways, no one who tries to answer your question is going to be able to get past thinking "Well, the paths must be different somehow...", so adding that information greatly increases your chances of getting a helpful answer, without any corresponding drawback. May as well go ahead and do it, don't you think? –  Aaron Miller Dec 11 '13 at 21:05
    
I've added both %PATH% as correctly suggested. If we compare them they look almost the same except the "Open command window here" version display environment variables as such and not their value ( (id. %ProgramFiles(x86)% instead of C:\Program Files (x86) as in the (working) standard console). –  CDuv Dec 11 '13 at 21:45
    
@CDuv The "open command window here" version not expanding environment variables seems rather likely to be at the root of the problem. I don't really know what you can do about that, but this Super User question and its answers look like they might make a good place to start. –  Aaron Miller Dec 11 '13 at 22:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.