Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Content-Type: text/plain; charset="iso-8859-1" From: "Michael Teske" Organization: CSK Software AG To: cygwin@cygwin.com Subject: Re: Strange behavior of MSVC's printf under cygwin shell? Date: Tue, 26 Mar 2002 16:23:16 +0100 References: <4.3.1.2.20020325164805.02361a90@pop.ma.ultranet.com> <3CA02B81.8D679A34@tin.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/