X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4AFF05F3.5060706@gmail.com> Date: Sat, 14 Nov 2009 19:33:07 +0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: How to capture stderr of dos process running in bash shell?? References: <26341304 DOT post AT talk DOT nabble DOT com> <4AFE14EB DOT 5020305 AT gmail DOT com> <20091114185556 DOT GA15089 AT ednor DOT casa DOT cgf DOT cx> In-Reply-To: <20091114185556.GA15089@ednor.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Christopher Faylor wrote: > But that is clearly not the case here since stdout and stderr are being > bypassed and text is still showing up on the screen. That is not a symptom > of stdout/stderr being attached to a pipe. > > Although, hmm, on rereading it isn't clear that the output shows up on > the screen. It sounds like the DOS program just might not differentiate > between stdout and stderr. I checked: you can't redirect its error output at all, even in a genuine cmd.exe shell with cygwin having nothing to do with it. It must indeed be using the console directly. Curiouser and curiouser... it links msvcrt.dll and imports printf and wprintf, but then it goes and actually does everything the hard way with lowlevel console i/o in unicode. How peculiar. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple