Date: Tue, 9 Jul 2002 16:28:02 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Alex <alex AT compuweigh DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Stderr redirection problems
In-Reply-To: <36F74B8910ED2E4AB98A2E8829085F15173F@email2k.compuweigh.com>
Message-ID: <Pine.SUN.3.91.1020709161954.16639C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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

[Please keep the discussion on the mailing list.]

On Tue, 9 Jul 2002, Alex wrote:

> Strange thing happens though. At start-up the program normally outputs
> to the COM3 the following data:
> 
> POWER UP TIME <time> DATE <date>
> REMOTE MODE IDLE <time>
> 
> If something sent to stderr at this point, the program only gets to
> print this data partially, even though it sends the whole chunk to COM3 at
> once not by single character.

I suspect that this output is buffered by your program (does it use 
printf to do that?), so what you see is that only part of the buffered 
output is printed.

> So, it looks like redir intervenes with its output
> to COM3 at this moment and shuts down any further access to COM3 for the
> main program.

As I told earlier, redir cannot intervene: it's dormant at this point.  
All redir does is invoke your program with stderr redirected to the COM3 
port.  After that, it's your program which sends the data through stderr 
to COM3, not redir.

In other words, what happens is that once your program prints something 
through stderr to COM3, COM3 is preempted by stderr and the data you 
print through the other file descriptor never gets to the printer.

Does adding fflush to the place where you print data to the printer 
solve the problem?

> > Finally, do you really need `redir' at all?  Why can't you redirect
> > stderr to COM3 from within your application?  You do have the sources,
> > right?
> Yes, that's correct, except one thing - I want redir to capture the
> crash dump in case the application goes down and send it to the printer.

If you redirect stderr to COM3 from within the application, the crash 
dump will go to COM3 as well.  The code which prints the crash dump 
simply writes file handle 2, it doesn't care where is that handle 
connected.