Solve : Have to be in C:\Windows\System32 to run files in that folder?

1.	Solve : Have to be in C:\Windows\System32 to run files in that folder?
Answer» ...and I thought that SINCE that is in the System Path, I could run files in C:\Windows\System32 from anywhere? More specifically - I can run any program in C:\Windows\System32 from the Windows Run box. But if I'm in cmd.exe at some other directory - say C:\Windows - and try to run a program that is in C:\Windows\System32 (and does work in cmd.exe), it will say something of the sort "'edlin' is not recognized as an internal or external command, operale program, or batch file". Yet, "C:\WINDOWS\system32" is in the path, and edlin.exe works when when I'm in C:\Windows\System32. Is it possible to get cmd.exe to run commands that aren't built-in to it from any directory, or is this not possible in cmd.exe? OS: Windows XP SP2, version 5.1.2600.Check your path again. Type PATH at the prompt and post what you get. The normal behaviour for cmd.exe is to search for executables first in the current directory and then in each folder listed in the PATH environment variable. Is anything getting changed in autoexec.nt? If you type SET at the command prompt you should see a list of all the environment variables. Are these like so? ComSpec=C:\WINDOWS\system32\cmd.exe Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH windir=C:\WINDOWS Another possibilty is a malware infection... Quote from: Dias de verano on July 21, 2008, 12:23:45 AM Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; <may be much more, but the first 2 in blue should be at the beginning That's it! Java had pre-empted Windows at the beginning of my path, and once I moved it back in the queue and restarted, it worked just like I thought it should! Thanks! This happened to me, and I SUSPECT a number of other people. For some reason I'm not sure of, the java install sometimes ADDS the Java binaries folders to the beginning of the PATH system variable, instead of appending them to the end as they should be. Furthermore it does it badly so that the PATH becomes malformed. As you can see, the PATH system variable is a semicolon-separated list of folder paths. For commands external to cmd.exe, the system searches each folder in the PATH system variable in turn. If the list becomes DAMAGED in some way (e.g. a missing semicolon), before it gets to "C:\WINDOWS\system32;C:\WINDOWS;" then the system just gives up & you get the "not recognized as an internal or external command" message. That's why these folders should be at the start. That way, the system finds the commands fast, early in the search. An unfortunate side effect of this method hunting along the PATH variable is that by adding a folder to the beginning of the PATH you can intentionally or accidentally pre-empt an external command with another identically named .exe, since the system executes the first one that it finds.

Answer»

...and I thought that SINCE that is in the System Path, I could run files in C:\Windows\System32 from anywhere?

More specifically - I can run any program in C:\Windows\System32 from the Windows Run box. But if I'm in cmd.exe at some other directory - say C:\Windows - and try to run a program that is in C:\Windows\System32 (and does work in cmd.exe), it will say something of the sort "'edlin' is not recognized as an internal or external command, operale program, or batch file". Yet, "C:\WINDOWS\system32" is in the path, and edlin.exe works when when I'm in C:\Windows\System32.

Is it possible to get cmd.exe to run commands that aren't built-in to it from any directory, or is this not possible in cmd.exe?

OS: Windows XP SP2, version 5.1.2600.Check your path again. Type PATH at the prompt and post what you get.

The normal behaviour for cmd.exe is to search for executables first in the current directory and then in each folder listed in the PATH environment variable. Is anything getting changed in autoexec.nt?

If you type SET at the command prompt you should see a list of all the environment variables. Are these like so?

ComSpec=C:\WINDOWS\system32\cmd.exe
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
windir=C:\WINDOWS

Another possibilty is a malware infection...
Quote from: Dias de verano on July 21, 2008, 12:23:45 AM

Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; <may be much more, but the first 2 in blue should be at the beginning

That's it! Java had pre-empted Windows at the beginning of my path, and once I moved it back in the queue and restarted, it worked just like I thought it should! Thanks! This happened to me, and I SUSPECT a number of other people. For some reason I'm not sure of, the java install sometimes ADDS the Java binaries folders to the beginning of the PATH system variable, instead of appending them to the end as they should be. Furthermore it does it badly so that the PATH becomes malformed.

As you can see, the PATH system variable is a semicolon-separated list of folder paths. For commands external to cmd.exe, the system searches each folder in the PATH system variable in turn. If the list becomes DAMAGED in some way (e.g. a missing semicolon), before it gets to "C:\WINDOWS\system32;C:\WINDOWS;" then the system just gives up & you get the "not recognized as an internal or external command" message. That's why these folders should be at the start. That way, the system finds the commands fast, early in the search.

An unfortunate side effect of this method hunting along the PATH variable is that by adding a folder to the beginning of the PATH you can intentionally or accidentally pre-empt an external command with another identically named .exe, since the system executes the first one that it finds.

Solve : Have to be in C:\Windows\System32 to run files in that folder?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment