WSHshell.run command parsing strangeness

Perkin@discussions.microsoft.com Tom Perkin

unread,

Jul 19, 2004, 12:25:05 PM7/19/04

to

I noticed today that one of my scripts appears to have broken at some point in the past few months, possibly as a result of installing a security update. My script runs xcopy, but the run method was returning the error message "Unable to wait for process". After much hair-tearing, I established that this was because there was a folder in the "current directory" called xcopy, and this was causing the problem. So it appears that if there is a folder with the same name as a command that is called with WSHshell.run, a problem occurs.

For example, make a folder called "dir". Then make a vbs script like:

set oSh = createObject("Wscript.shell")
ret = oSh.run("dir >dir.out",0,true)

and execute the vbs in the folder containing the "dir" folder. Perhaps someone can shed some light on what caused this to start happening. Unless I'm weird in assuming that this method shouldn't try to execute folders.

Warm regards,

-tom

Tom Lavedas

unread,

Jul 19, 2004, 1:27:03 PM7/19/04

to

The problem is that Windows is trying to open the folder into explorer. At least, that's what it did for me, when I changed the window type to one in the Run statement.

The solution is very easy and is in fact necessary to support redirections, anyway. Simply invoke the command processor explicitly, something like this ...

set oSh = createObject("Wscript.shell")

ret = oSh.run("%comspec% /c dir >dir.out",0,true)

I suspect the problem started with the creation of the folder named Xcopy, not with the installation of a security patch.

BTW, the example you used will not work as posted, since DIR is one of many command line statements hosted by the command processor.

Tom Lavedas
===========

Torgeir Bakken (MVP)

unread,

Jul 19, 2004, 2:14:18 PM7/19/04

to

Tom Perkin wrote:

Hi

For executables, my rule is to always add the .exe extension in the
Run statement to avoid this type of problems, so use "xcopy.exe"
instead of "xcopy" (note that dir is not an executable as it lives
"inside" cmd.exe)

--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/community/scriptcenter/default.mspx

Tom Perkin

unread,

Jul 20, 2004, 9:44:02 AM7/20/04

to

// Directory listing

C:\lsbackup>dir
Volume in drive C is W2KPRO
Volume Serial Number is 209A-5AC7

Directory of C:\lsbackup

19/07/2004 17:40 <DIR> .
19/07/2004 17:40 <DIR> ..
<snip>
19/07/2004 16:44 <DIR> dir
19/07/2004 16:45 213 dir.vbs

// dir.vbs
' dir.vbs
set oSh = CreateObject("Wscript.shell")
ret = oSh.Run("dir > dir.out",0,true)
msgbox ret
set oSh = nothing

C:\lsbackup\dir.vbs(6, 1) WshShell.Run: Unable to wait for process.

So it seems to happen regardless. I am moderately sure that this has only recently started happening.

I changed the xcopy commands to explicitly call the binary rather than rely on the execution path, which is probably neater anyway.

Warm regards,

-tom

Tom Lavedas

unread,

Jul 20, 2004, 1:45:03 PM7/20/04

to

No, you completely misconstrued my meaning. The explicit reference to the command processor MUST be in the Run statement. Simply running it from the command prompt has absolutely no impact on the result! The Run statement MUST be changed from this ...

ret = oSh.Run("dir > dir.out",0,true)

to this ...

ret = oSh.Run("%comspec% /c dir > dir.out",0,true)

for the problem to be solved.

Further, as both Torgeir and I pointed out, redirection will NOT work, unless the command processor is invoked IN THE RUN STATEMENT.

I am still convinced, your problem is in the way you are using the Run method (and/or the way you are naming folders) and has nothing to do with a security patch.