Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Content-Type: text/plain; charset="iso-8859-1" From: "Michael Teske" Organization: CSK Software AG To: cygwin AT cygwin DOT com Subject: Re: Strange behavior of MSVC's printf under cygwin shell? Date: Tue, 26 Mar 2002 16:23:16 +0100 References: <4 DOT 3 DOT 1 DOT 2 DOT 20020325164805 DOT 02361a90 AT pop DOT ma DOT ultranet DOT com> <3CA02B81 DOT 8D679A34 AT tin DOT it> In-Reply-To: <3CA02B81.8D679A34@tin.it> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: X-Virus-Scanned: by AMaViS snapshot-20010407 On Tuesday 26 March 2002 09:04, Pietro Toniolo wrote: > Nay, I campiled the proposed program (every package on my side is in the > "Last" status) and, with -no-cygwin, I do have an unbuffered stdout. You mean buffered? > Is it an "undefined behavior" of the c compiler? > But why a different default behavior, with and without the flag? Usually the libc decides if to use buffering by the fact if stdout is atttached to a terminal (line buffering) or redirected to a file (full buffering). Since -no-cygwin uses the MS libc, and MS libc doesn't know anything about bash, I suppose they thing stdout is not connected to a terminal when running under bash. This would at least explain this behaviour and there would be nothing you can do about it, except using fflush (as a lot of people already suggested). Greetings, -- Michael Teske -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/