From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19925 invoked by alias); 4 Apr 2012 14:03:03 -0000 Received: (qmail 19914 invoked by uid 22791); 4 Apr 2012 14:03:02 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mho-01-ewr.mailhop.org (HELO mho-01-ewr.mailhop.org) (204.13.248.71) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Apr 2012 14:02:49 +0000 Received: from pool-98-110-186-28.bstnma.fios.verizon.net ([98.110.186.28] helo=cgf.cx) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SFQnQ-000DiW-Km for cygwin@cygwin.com; Wed, 04 Apr 2012 14:02:48 +0000 Received: from localhost (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id EF7A413C076 for ; Wed, 4 Apr 2012 10:02:47 -0400 (EDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1987nqbAYxOLW7aRioBl4M5 Date: Wed, 04 Apr 2012 14:03:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: input delay issues Message-ID: <20120404140247.GA19662@ednor.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <4F7A022B.6040702@towo.net> <20120402205607.GD9912@ednor.casa.cgf.cx> <4F7B501C.5020900@towo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F7B501C.5020900@towo.net> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-04/txt/msg00146.txt.bz2 On Tue, Apr 03, 2012 at 09:31:40PM +0200, Thomas Wolff wrote: >Am 02.04.2012 22:56, schrieb Christopher Faylor: >>On Mon, Apr 02, 2012 at 09:46:51PM +0200, Thomas Wolff wrote: >>>When input is typed-ahead, on a Unix or Linux systems it will be >>>buffered and used as soon as an application looks for it. Try this: - >>>Run a slow command (e.g. sleep 5) - Type "abc" while running On Linux, >>>"abc" will be echoed on the screen (disturbing output if there is any). >>>After the command terminates, the shell will look for input, find "abc" >>>and redisplay it properly on the command line. >>> >>>In the cygwin console, "abc" remains invisible while the command is >>>running, but it is redisplayed afterwards. In mintty, "abc" is echoed >>>while typed-ahead, but is *not* read and echoed by the shell after the >>>command terminates. Only after you then type another character, the >>>whole command line is refreshed. >> >>Yes. The console is a windows device and that's the way that Windows >>works. Doing it anyway else would mean keeping a separate thread in >>Cygwin and essentially adding back CYGWIN=tty, which we're obviously >>not going to do. > >OK, so there is a clear background explaining the console behavior; >however, I described it only for completeness and to compare, the >actual problem is with mintty/xterm/urxvt: Input which is available is >not being detected - this is likely to be a problem with select() or >O_NONBLOCKed read() (whichever bash uses) or both. You have asserted this several times but I don't believe you've provided a test case. cgf -- 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