X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Date: Wed, 14 Apr 2010 23:25:43 +0300 From: Eli Zaretskii Subject: Re: redirect stderr to stdout/file in djgpp 2.x In-reply-to: X-012-Sender: halo1 AT inter DOT net DOT il To: djgpp AT delorie DOT com Message-id: <83633tye60.fsf@gnu.org> References: <97e7dd63-3c51-4796-a5ba-c8a1cddaabbc AT w17g2000yqj DOT googlegroups DOT com> <57a05b96-b688-4c09-93b5-f2bd3d2501a1 AT r18g2000yqd DOT googlegroups DOT com> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Rod Pemberton" > Date: Wed, 14 Apr 2010 14:22:59 -0400 > Bytes: 2283 > > 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.