4

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.

Improve this question
5
  • 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, 2011 at 23:21
  • Hylltun can you edit your post and post the output of typing in path on the Command Prompt ?
    – Sathyajith Bhat ♦
    Jan 30, 2011 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, 2011 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, 2011 at 19:15
  • @Daniel: Ok, will do.
    – Garrett R. Hylltun
    Feb 8, 2011 at 5:00

6 Answers 6

Reset to default
1

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.

Improve this answer
2
  • 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, 2011 at 22:22
  • Fair enough, it is puzzling.
    – Tobias Plutat
    Jan 27, 2011 at 23:11
1

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.

Improve this answer
1
  • 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, 2012 at 8:27
1

.EXE might be removed from PATHEXT in environment variable.

If this is the case add .EXE to PATHEXT.

Improve this answer
0

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).

Improve this answer
9
  • I honestly didn't know there were separate sessions for the console window.
    – Garrett R. Hylltun
    Jan 28, 2011 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, 2011 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, 2011 at 8:08
  • @Garrett: What is the .exe called? Have you tried renaming it to something else?
    – paradroid
    Jan 30, 2011 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, 2011 at 6:28
0

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

Improve this answer
1
  • 1
    Welcome to Super User! Are you sure you're... answering the right question? This hardly seems to have any relevance.
    – Thor
    Dec 31, 2013 at 11:33
0

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'

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .