Why do some processes started at the command line on my Windows machine block/buffer their entire output if it is redirected and others not?
Example: tracert
does not block/buffer output as it is written. If one executes:
tracert ponyoverflow.com > output.txt
...the output.txt
file grows over time. This is completely how I would expect things to behave.
But, I'm trying to work with a potential vendor's software product (iSpring SDK, if you must know) and it seems to buffer the complete output until the process has finished. What I find confusing is that when this softwar开发者_运维知识库e is run at the command line the output comes piecemeal, line-by-line, as expected.
Why is there a difference in behavior between calling it with and without output redirection?
Follow up miscellaneous questions:
- Is this common and/or standard in the world of Windows command line programming?
- Is there anything I can do to grab the
- How do I communicate exactly, in Windows programmer parlance, to iSpring folks how I think their software should behave at the command line?
I'm not sure how important it is, but all this experimentation of mine is happening on a 64-bit Windows 7 Home Premium machine.
(The folks at iSpring were much quicker responding to me requests than I could have dreamed. Spot on. Here is their answer to 'why' below.)
Standard output in C++ is buffered by default. The buffer size is about 4KB. The buffer is flushed when the application finishes. Data written to stdout are not buffered when standard output is connected with a console.
精彩评论