Well, your program doesn't work for me either - what platform are you on? Please note that the Java program I wrote does not process command line arguments like your script does below. The call to perl is entirely hardcoded and the script should only output is "Hello World, Hello Avi\n".

Looking at that article, I'm wondering where you found concerns that the buffer is liable to be emptied out before Java code has a chance to read it. The problems it discusses don't seem related to that at all. They also don't seem to explain Avi's failed output. They include:

• the command causing thread violations by failing to wait for the process to finish before fetching the exit code. Avi's script (and mine) only check the exit code after calling waitfor so this isn't an issue here.

• the command hanging due to buffer overflow- The issue being discussed in the article are buffers that are too full, not buffers emptied out. The overfull buffer prevents the process from further writes and it hangs waiting for the buffer to empty out so it can do the next write. This is the exact opposite of a buffer that empties out by the time the process finishes. Even if the process doesn't hang, the symptom of this problem would be truncated output (only the first N characters), not entirely missing output.

  Although the risk of buffer overflow merits a change to the script I offered (to poll output while the process is running rather than slurping it after the process completes), it does not explain Avi's lack of output. Also, Avi did not report hanging. In any case it is unlikely that the maximum buffer size for interprocess communication on MsWin is < 32 bytes. ("hello world. Hello avi!\n" is 26 characters (26 bytes UTF8, I believe since all the characters are Latin1)).

• seeing no output because the command spits output to stderr, and the programmer is only checking stdout. This program is clearly writing to stdout, so this does not apply either.

• seeing no output because the command was a built-in shell command and can't be run without calling "cmd.exe". Neither perl, ratlperl, nor cqperl are built-in shell commands.

The author's solution is also somewhat questionable: passing everything to "cmd.exe". This introduces additional issues of shell interpretation, quoting, etc and generally makes the calling process more complex. It also adds overhead as we now need to launch 2 processes (cmd.exe and cqperl.exe) rather than 1. Avi ought to be able to call his command without diving into the "cmd.exe" and if he can't something is wrong that needs to be understood.