This question has been asked more than once before, but I have not found a satisfactory answer in any of those discussions.
I am launching a command-line process that produces a real-time measurement to STDOUT, producing a new result approximately every second. Using System.Diagnostics.Process.StandardOutput results in completely unacceptable lag (over 20 seconds) as the STDOUT data works through the 4k buffer in the Process.StandardOutput StreamReader, and there doesn’t seem to be any way to get around this.
Calling Process.StandardOutput.BaseStream.Flush() doesn’t work.
I’ve tried doing a byte-by-byte synchronous read of Process.StandardOutput, but I’m still 4k behind the actual output.
Can anyone at least verify for me that it is possible to somehow overcome all of the buffering issues I am having with redirecting STDOUT, and receive the data in my application as soon as it would have appeared in the shell window? Can I inherit from the Process class and change how the StandardOutput streamreader behaves? Do I need to be looking at raw WINAPI calls?
Somehow, this has to get done, even if I end up writing unmanaged C++ to launch the task and consume the output, and linking that in. Any help is much appreciated; I’m at my wit’s end…
Edit: It appears that what I need is a .Net implementation of the “expect” libraries that are available for C/C++, Perl, Python, and Java (those are the only ones I have found so far). Does anyone know if such a beast exists?
“[I]s there a way to launch it such [that] it doesn’t realize it is being redirected?” YES: that is exactly the domain of Expect. I know of no .Net implementation; it’s surely feasible, though …