Date: Tue, 9 Jul 2002 08:27:00 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Alex Oleynikov cc: djgpp AT delorie DOT com Subject: Re: Stderr redirection problems In-Reply-To: Message-ID: 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 On Mon, 8 Jul 2002, Alex Oleynikov wrote: > The COM3 has a serial printer attached to it, which is used by the main > program as an audit trail printer to print legal information about the > user's actions (I use PMCOM to communicate with serial devices). > Now, everything is OK up until the moment when something is output to the > stderr stream. From that moment on the serial printer becomes invisible to > my program - nothing gets printed when the program sends it to COM3. Still, > the stderr output intercepted by redir gets down to the printer without any > problems. > > It looks like redir keeps that COM-port open all the time after the first > moment it was accessed by this utility and this prevents the main program > from getting access to it. Actually, `redir' opens the COM3 port even before it runs the application. It has no way of knowing whether something is actually output to the port (to say nothing of the fact that while the application executes, `redir' is suspended--this is DOS, remember?--and so none of `redir's own code can run). Is this on Windows or in plain DOS? If the former, it might be some quirk of how Windows virtualizes the COM ports. What happens if you try "redir -ea COM3" instead of just -e? Does it help to open COM3 from your application in `append' mode? 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?