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 recently had to test connectivity with another computer on my home network. As I had always done, I launched CMD.EXE and a black, familiar window is opened, with a title saying that I am the Administrator (wow!). I type PING followed by the URL, and it says that PING is not a recognized command. I make a quick search for PING.EXE, and it is in Windows/System32. I then repeat the command using the full path, and it works. It happens that System32 is not in the PATH of the shell.

How did it get removed from the path, and how should I put it back?

share|improve this question
1  
It’s not another (or any) “Microsoft scheme” to take power away from users (which doesn’t make sense anyway); %systemroot%\system32 should be in the path by default, so you must have done something or installed something that messed up the path. What is in the path? Look at that and it should give you a clue as to what went wrong your system. –  Synetech Aug 2 '12 at 14:58
add comment

migrated from webapps.stackexchange.com Aug 2 '12 at 10:19

This question came from our site for power users of web applications.

2 Answers

You can make it work by following these steps:

  1. Right-click on Computer > Select Properties
  2. In System Properties click the Advanced tab > Click Environment Variables... button
  3. Under System variables scroll down to Path and double click it
  4. Click on the Variable value text field and move the cursor to the front
  5. Paste this: %SystemRoot%\system32;
  6. Click Okay to close the open dialogs, and restart if necessary.

The Path environmental variable allows you to type program names from any directory. Windows will check the directories listed there if it can't find the command in the current directory.

share|improve this answer
    
You explained how to fix it, but did not answer the question as to why it is not correct in the first place. –  Synetech Aug 2 '12 at 14:55
add comment

Check to see if you have a file called autoexec.nt which is messing with your PATH variable.

Also, note that the PATH variable is read sequentially. If the first location in PATH is not available (eg the directory has been deleted or renamed), none of the other locations will be checked.

share|improve this answer
    
> Also, note that the PATH variable is read sequentially. If the first location in PATH is not available (eg the directory has been deleted or renamed), none of the other locations will be checked. That’s not true at all. Where did you get that? o.O –  Synetech Aug 2 '12 at 14:56
    
Well, first reference I can find for this is at: blogs.msdn.com/b/oldnewthing/archive/2012/02/08/10265193.aspx –  Adam Thompson Aug 2 '12 at 15:10
1  
That’s only for PATHs that include network locations (which is rare in general, and highly unlikely for the OP). You can test for yourself that PATHs with missing local directories are indeed skipped. Nonetheless, thanks for the link because I for one had not even considered putting network locations in the PATH, let alone that broken ones would cause PATH-searching to abort. –  Synetech Aug 2 '12 at 15:13
    
I don't have a test box right now, but I'm pretty sure it also applies to broken/missing directories on the local disk. I am sure I have used this quirk to avoid some PERL-based application from finding the wrong perl DLLs when installing. –  Adam Thompson Aug 2 '12 at 15:20
    
Update: Mea Culpa. I just tested this on a WS2003 test machine. You're right - it doesn't apply to dirs on local fixed disks. –  Adam Thompson Aug 2 '12 at 15:29
show 1 more comment

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.