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.

A few years back I made a couple of console command line apps which at the time worked with no issues. I'd place them in the window/system32 directory and be able to use them from the console prompt from anywhere on my system(Windows XP at that time).

Now I'm using Windows 7 64bit and this no longer works. I've tried placing my little console apps in system32, syswow64, Windows on down to the root of my c: drive, but windows continues to give me the same reply "'check' is not recognized as an internal or external command, operable program or batch file."

But! If I am within the same directory as the program it works as intended. I'm assuming there's either a 32bit/64bit app issue or OS internal security issue.

Can anyone point me in the right direction here? Do I need to create a directory in "Program Files(x86) and add that new directory to the PATH environment?


Additional Note: This is a program I created. It is not a batch file. The program does work as it should when you are in the same directory as the program while you are in a console window.

share|improve this question
    
Just to be sure we're on the same page: Are we talking about batch files here, or is it something else? –  Tobias Plutat Jan 27 '11 at 23:21
    
Hylltun can you edit your post and post the output of typing in path on the Command Prompt ? –  Sathya Jan 30 '11 at 4:33
    
Microsoft Windows [Version 6.1.7600] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\System32>echo %PATH% The system cannot find the file specified. C:\Windows\System32> –  Garrett R. Hylltun Jan 31 '11 at 6:41
    
Post your findings as an answer to your own question and accept it by clicking on the checkmark as soon as it's available. This will mark this question as answered. –  Daniel Beck Feb 7 '11 at 19:15
    
@Daniel: Ok, will do. –  Garrett R. Hylltun Feb 8 '11 at 5:00

6 Answers 6

The easiest way, though, would be utilizing Windows's PATH environment variable. It ensures 100% the same functionality and doesn't involve you putting anything into the Windows directory. There's other questions directed at the same thing, the answers in this thread should put you up to that.

share|improve this answer
    
A fair answer, but if he's already dropped them in the Windows System32 folder, wouldn't it be recognised, since that's already in the default path? –  user3463 Jan 27 '11 at 22:22
    
Fair enough, it is puzzling. –  Tobias Plutat Jan 27 '11 at 23:11
up vote 1 down vote accepted

The environmental variable for PATH did not contain the windows directory nor either of the system directories. I added all three paths to the PATH variable and now everything works as intended.

Thanks to everyone who replied with ideas, suggestions and questions.

share|improve this answer
    
You say "thanks to everyone ..." Well the best way to say thanks is really to up-vote the answer(s) that helped you (even though none was directly the answer to your question). It is a good way to provide your own answer with the sollution and mark it as the answer as you did here, but if any other answers helped you on the way, you should give them an up-vote. –  awe Mar 5 '12 at 8:27

.EXE might be removed from PATHEXT in environment variable.

If this is the case add .EXE to PATHEXT.

share|improve this answer

You're not saying whether you're running the program from a 32-bit command prompt or a 64-bit one. The 32-bit one will look in the SysWOW64 directory (it will see it as System32), and the 64-bit one will look in the System32 directory. (This should be a comment but I don't have enough rep to comment yet.)

If it's not clear, the 64-bit one is C:\Windows\System32\cmd.exe, the 32-bit one is C:\Windows\SysWOW64\cmd.exe. If you're ever not sure what the bitness of an open prompt is, just run the 'set' command and look at the value of the 'ProgramFiles' environment variable. The 64-bit prompt should show it as C:\Program Files, the 32-bit one as C:\Program Files (x86).

share|improve this answer
    
I honestly didn't know there were separate sessions for the console window. –  Garrett R. Hylltun Jan 28 '11 at 6:06
    
It's understandable, Windows only gives you one shortcut (in Start Menu > All Programs > Accessories), and that is for the 64-bit console. So you have to make your own shortcut to the 32-bit console. –  Chuck Heatherly Jan 28 '11 at 19:00
    
Placed my program back into the Windows dir, tried both cmd.exe, the one in system32 and the one in syswow64, and same thing with both, program isn't recognized from the c: root, but if I cd to windows it all works fine. This is really confounding. –  Garrett R. Hylltun Jan 29 '11 at 8:08
    
@Garrett: What is the .exe called? Have you tried renaming it to something else? –  paradroid Jan 30 '11 at 6:07
    
it's currently named check.exe but I'll rename it and see if that does the job. –  Garrett R. Hylltun Jan 31 '11 at 6:28

Regarding the part where you get "is not recognized as an internal or external command", take a look at this article:

Cannot Ping getting 'ping is not recognized as an internal or external command'

share|improve this answer

1.>make Android folder in C drive (C:\Android) 2.>paste debug.keystore in Android Folder (C:\Android\debug.keystore)

keytool -exportcert -alias androiddebugkey -keystore "C:\Android\debug.keystore" | "C:\OpenSSL-Win32\bin\openssl.exe" sha1 -binary | "C:\OpenSSL-Win32\bin\openssl.exe" base64

share|improve this answer
1  
Welcome to Super User! Are you sure you're... answering the right question? This hardly seems to have any relevance. –  Thor Dec 31 '13 at 11:33

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.