0

I'm trying to run a console app and read/write it's standard i/o. The problem is that, when this app writes to the output via WriteFile(GetStdHandle(...)), I successfully read it's input with ReadFile on the pipe.

When the target app uses fprintf, then ReadFile blocks until the target app exits, in which case it returns the entire output at once. When the target app blocks (say, via fgets()), then ReadFile blocks.

I 'm using standard pipe redirection: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499(v=vs.85).aspx.

Why is that strange behaviour and how do I get around it?

tshepang
  • 10,772
  • 21
  • 84
  • 127
Michael Chourdakis
  • 8,819
  • 2
  • 32
  • 61
  • Dup of http://stackoverflow.com/questions/1716296/why-does-printf-not-flush-after-the-call-unless-a-newline-is-in-the-format-strin – josh poley Aug 29 '13 at 20:12

1 Answers1

1

It is likely due to the fact that fprintf is buffered while WriteFile is not. Can you use fflush after fprintf and try the same ?

user1952500
  • 6,068
  • 3
  • 20
  • 34
  • I can, but what about an application that does not use fflush? How should I handle that? – Michael Chourdakis Aug 30 '13 at 06:08
  • 1
    For that case nothing can be done. In fact you cannot guarantee that the app alone (without the pipe) will print anything until the time it exits. Hence behavior will not be much different from redirected to a pipe or printed to stdout. – user1952500 Aug 30 '13 at 19:32