If you type
cmd /? at a command prompt, the command
processor will spit out pages upon pages of strange geeky text.
I'm not sure why the command processor folks decided to write
documentation this way rather than the more traditional manner
of putting it into MSDN or the online help.
Maybe because that way they don't have to deal with annoying
people like "editors" telling them
that their documentation contains grammatical errors or
is hard to understand.
Anyway, buried deep in the text is this little gem:
If /D was NOT specified on the command line, then when CMD.EXE starts, it looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if either or both are present, they are executed first. HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun and/or HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
I sure hope there is some legitimate use for this setting, because the only time I see anybody mention it is when it caused them massive grief.
I must be losing my mind, but I can't even write a stupid
forcommand to parse the output of a command.C:\test>for /f "usebackq delims=" %i in (`dir /ahd/b`) do @echo %i
When I run this command, I getRECYCLER System Volume Information WUTemp
Yet when I type the command manually, I get completely different output!C:\test>dir /ahd/b test_hidden
Have I gone completely bonkers?
The original problem was actually much more bizarro because the command whose output the customer was trying to parse merely printed a strange error message, yet running the command manually generated the expected output.
After an hour and a half of head-scratching, somebody suggested
taking a look at the command processor's
setting, and lo and behold, it was set!
C:\test>reg query "HKCU\Software\Microsoft\Command Processor" /v AutoRun ! REG.EXE VERSION 3.0 HKEY_CURRENT_USER\Software\Microsoft\Command Processor AutoRun REG_SZ cd\
The customer had no idea how that setting got there,
but it explained everything.
When the command processor ran the
dir /ahd/b command
as a child process (in order to parse its output),
it first ran the
which changed the current directory to the drive's root.
As a result, the
produced a listing of the hidden subdirectories of the root directory
rather than the hidden subdirectories of the
In the original formulation of the problem, the command the customer
was trying to run looked for its configuration files in the current
directory, and the
cd\ in the
meant that the program looked for its configuration files in the
root directory instead of the
Thus came the error message ("Configuration file not found")
and the plea for help that
was titled, "Why can't the XYZ command find a configuration file
that's right there in front of it?"
Like I said, I'm sure there must be some valid reason for the
but I haven't yet found one.
All I've seen is the havoc it plays.