Mail Archives: djgpp/2010/05/05/17:15:14
"Eli Zaretskii" <eliz AT gnu DOT org> wrote in message
news:83633tye60 DOT fsf AT gnu DOT org...
> > "Rod Pemberton" <do_not_have AT havenone DOT cmm>
> >
> > I've noticed that both John's TSR and DJGPP's redir.exe don't interleave
> > stderr and stdout messages the way they are emitted to the screen. Both
> > seem to write out stderr messages to the file first followed by stdout.
>
> Actually, redir.exe does nothing of the kind. In particular, it
> doesn't write anything, and thus cannot control the order in which
> stdout and stderr output are interleaved. What redir.exe does is just
> redirect stderr to the same file or device as stdout. The actual
> writes are done by the program that is invoked under redir.exe.
>
> It could be that you get the _impression_ that this is what redir.exe
> does, because stderr is usually unbuffered, and so tends to be flushed
> by the library and the OS sooner than stdout. But this is something
> redir.exe has no control of, and cannot change, the way it was
> designed and implemented.
>
OpenWatcom 16-bit/32-bit app's also interleave stderr and stdout message
correctly when emitted to the screen but fail to do so when redirected to a
file via redir.exe or John's TSR. When redirected to a file, all stderr
messages are first and all stdout messages are last. So, it seems this is
something to do with DOS' redirection mechanism. Or, perhaps it's an issue
with DOS' buffering as you've stated.
Rod Pemberton
- Raw text -