Differences in piping an executable and "exec ... >@xxx 2>@xxx"
From: Martin Lemburg (martin.lemburg.ugs_at_gmx.net)
Date: 26 Sep 2004 04:50:41 -0700
following situation - we have an executable (C main, F90 dll) from a
supplier and this executable delievers text at stdout via "printf". We
started this executable via "open |..." and at the end of the
execution, after exit we received not bit of the text printed to
stdout! Even introducing "fflush(stdout)" didn't help!
We started the executable simply with exec and got again not a char of
the text printed via printf to stdout.
So we built an own little executable (evaluating a tcl script using
"puts") using "printf" to print text from C to stdout, flushing the
used channels ("fflush(stdout)") and communicated via pipe ("open
|..."). At the end of the execution we missed all the printf results.
All texts printed from tcl via "puts" were piped correctly to the
Now we built the same little executable using "cout" instead of
"printf". The results of "cout" were piped to the calling application,
but seemed to be asynchronous to the "puts" used in the evaluated tcl
script. Even using "cout.flush()" didn't stop the asynchronous thing.
At last we started the executables via "exec" and using the
pipe-capabilities into files open by tcl for stdout and stderr ("exec
... >@file001 2>@file002"). We got all outputs ("printf"'s, "cout"'s
and "puts"') and we got them in the sequence we expected to get them!
What is going wrong and where are the differences between "open |..."
and "exec ... >@file001 2>@file002", belonging to the treatment of
"prinft", "cout" and "puts" in a "piped" application?
Thanks for any answer, or comment!
Unigraphics Solutions GmbH - UGS the PLM Company