Date: Wed, 4 Apr 2012 10:43:19 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Re: input delay issues
Message-ID: <20120404144319.GB21593@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <1268678816 DOT 345581 DOT 1333548784781 DOT JavaMail DOT open-xchange AT email DOT 1und1 DOT de> <4F7C599D DOT 3080004 AT towo DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F7C599D.3080004@towo.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Wed, Apr 04, 2012 at 04:24:29PM +0200, Thomas Wolff wrote:
>Christopher Faylor wrote:
>> 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.
>I described:
>- in mintty:
>- start sleep 3
>- quickly enter "abc"
>- wait until sleep terminates
>- look at prompt
>- type "d"
>Isn't that a test case?
>I understand an automatic test case, preferably a few lines of C code, 
>may be easier to handle and analyze; maybe I'll find one. Meanwhile, 
>this "manual test case" stays available.

That's good enough, yes.  I missed the mintty above.

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