Subject: Re: Stderr redirection problems
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 9 Jul 2002 10:02:11 -0400
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Message-ID: <36F74B8910ED2E4AB98A2E8829085F151740@email2k.compuweigh.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Stderr redirection problems
Thread-Index: AcInUTe5MDh8GjxLQKKD0Wc/orBs1w==
From: "Alex" <alex AT compuweigh DOT com>
To: <djgpp AT delorie DOT com>
Cc: <eliz AT is DOT elta DOT co DOT il>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g69Dtgm28745
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:

>[Please keep the discussion on the mailing list.]
??? I think I posted it to the newsgroup as well.

>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.

No, in fact I am using calls to PMCOM library to write directly to
COM-port (function COMWriteBuffer(...)).


>> 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.

OK, but since I am not doing this explicitly with my code, some other
code must be doing this for me and it prevents the access to COM3 from
the application.
So, essentially, to me it looks like something else cuts me off the COM3
- redir or standard input/output code bundled by the compiler, does not
matter.

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

Again, I am not using stdout to print to COM3, but direct calls to
PMCOM.

>> > 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.

Well, I cannot have COM3 open internally for both stderr and my
application's output at the same time, right?
Maybe you could suggest some other way of printing the crash dump
without using redir?
The reason I need this printout is because the application (in fact, it
is a scale controller) is installed all over the country and this is the
only way to get the feedback on possible program errors.

Thanks,
Alex