Capturing output from WshShell.Exec using Windows Script Host

Question

I wrote the following two functions, and call the second ("callAndWait") from JavaScript running inside Windows Script Host. My overall intent is to call one command line program from another. That is, I'm running the initial scripting using cscript, and then trying to run something else (Ant) from that script.

function readAllFromAny(oExec)
{
     if (!oExec.StdOut.AtEndOfStream)
          return oExec.StdOut.ReadLine();

     if (!oExec.StdErr.AtEndOfStream)
          return "STDERR: " + oExec.StdErr.ReadLine();

     return -1;
}

// Execute a command line function....
function callAndWait(execStr) {
 var oExec = WshShell.Exec(execStr);
  while (oExec.Status == 0)
 {
  WScript.Sleep(100);
  var output;
  while ( (output = readAllFromAny(oExec)) != -1) {
   WScript.StdOut.WriteLine(output);
  }
 }

}

Unfortunately, when I run my program, I don't get immediate feedback about what the called program is doing. Instead, the output seems to come in fits and starts, sometimes waiting until the original program has finished, and sometimes it appears to have deadlocked. What I really want to do is have the spawned process actually share the same StdOut as the calling process, but I don't see a way to do that. Just setting oExec.StdOut = WScript.StdOut doesn't work.

Is there an alternate way to spawn processes that will share the StdOut & StdErr of the launching process? I tried using "WshShell.Run(), but that gives me a "permission denied" error. That's problematic, because I don't want to have to tell my clients to change how their Windows environment is configured just to run my program.

What can I do?

Answer 1

You cannot read from StdErr and StdOut in the script engine in this way, as there is no non-blocking IO as Code Master Bob says. If the called process fills up the buffer (about 4KB) on StdErr while you are attempting to read from StdOut, or vice-versa, then you will deadlock/hang. You will starve while waiting for StdOut and it will block waiting for you to read from StdErr.

The practical solution is to redirect StdErr to StdOut like this:

sCommandLine = """c:\Path\To\prog.exe"" Argument1 argument2"
Dim oExec
Set oExec = WshShell.Exec("CMD /S /C "" " & sCommandLine & " 2>&1 """)

In other words, what gets passed to CreateProcess is this:

CMD /S /C " "c:\Path\To\prog.exe" Argument1 argument2 2>&1 "

This invokes CMD.EXE, which interprets the command line. /S /C invokes a special parsing rule so that the first and last quote are stripped off, and the remainder used as-is and executed by CMD.EXE. So CMD.EXE executes this:

"c:\Path\To\prog.exe" Argument1 argument2 2>&1

The incantation 2>&1 redirects prog.exe's StdErr to StdOut. CMD.EXE will propagate the exit code.

You can now succeed by reading from StdOut and ignoring StdErr.

The downside is that the StdErr and StdOut output get mixed together. As long as they are recognisable you can probably work with this.

Answer 2

Another technique which might help in this situation is to redirect the standard error stream of the command to accompany the standard output. Do this by adding "%comspec% /c" to the front and "2>&1" to the end of the execStr string. That is, change the command you run from:

zzz

to:

%comspec% /c zzz 2>&1 

The "2>&1" is a redirect instruction which causes the StdErr output (file descriptor 2) to be written to the StdOut stream (file descriptor 1). You need to include the "%comspec% /c" part because it is the command interpreter which understands about the command line redirect. See http://technet.microsoft.com/en-us/library/ee156605.aspx
Using "%comspec%" instead of "cmd" gives portability to a wider range of Windows versions. If your command contains quoted string arguments, it may be tricky to get them right: the specification for how cmd handles quotes after "/c" seems to be incomplete.

With this, your script needs only to read the StdOut stream, and will receive both standard output and standard error. I used this with "net stop wuauserv", which writes to StdOut on success (if the service is running) and StdErr on failure (if the service is already stopped).