Yesterday I started a thread and wished for it's deletion and poof, it was gone.
I wanted to follow up with my findings from experimenting with the Process Class and executing windows commands from inside a Java program.
I read the article about "When Runtime.exec() won't" but had a few comments about the info in that article. For starters, the article attempts to capture the stream from issuing a "javac" command. However, how does one know in advance that certain commands require an ErrorStream and certain commands only need the standard InputStream?
The article suggested the example of issuing "javac" was mediocre because the exitVal was = 2, however they never show you how to issue that command and get an exitVal=0
To me, I understand this to mean that issuing: "dir" produces an InputStream and issuing "javac" produces an ErrorStream. You can't output the stream from "javac" without the ErrorStream. When I try, the process hangs and no output is written.
Playing around with other windows system commands produces other error codes, such as exitVal=1 when you issue: "cmd.exe /c dir /?" You can output the stream using p.getInputStream, but the exitVal=1, which according to MSDN means that it is an "incorrect function".
Does this mean that capturing the stream from: "cmd.exe /c dir /?" was not implemented correctly, because the exitVal != 0 ?
When using Process, it's a good practice to read both the getInputstream (i.e, the stdout of the called process) and getErrorStream (i.e, the stderr of the called process).
If you have no special reason to process them separately, then a better approach is to use the ProcessBuilder class. Its redirectErrorStream() method allows the stderr of the called process to be redirected to its stdout; so only the getInputStream() needs to be read to get the contents of both streams.