* Re: Re: input delay issues [not found] <1268678816.345581.1333548784781.JavaMail.open-xchange@email.1und1.de> @ 2012-04-04 14:24 ` Thomas Wolff 2012-04-04 14:43 ` Christopher Faylor 0 siblings, 1 reply; 3+ messages in thread From: Thomas Wolff @ 2012-04-04 14:24 UTC (permalink / raw) To: cygwin 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. ------ Thomas -- 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Re: input delay issues 2012-04-04 14:24 ` Re: input delay issues Thomas Wolff @ 2012-04-04 14:43 ` Christopher Faylor 2012-04-05 15:19 ` Christopher Faylor 0 siblings, 1 reply; 3+ messages in thread From: Christopher Faylor @ 2012-04-04 14:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Re: input delay issues 2012-04-04 14:43 ` Christopher Faylor @ 2012-04-05 15:19 ` Christopher Faylor 0 siblings, 0 replies; 3+ messages in thread From: Christopher Faylor @ 2012-04-05 15:19 UTC (permalink / raw) To: cygwin On Wed, Apr 04, 2012 at 10:43:19AM -0400, Christopher Faylor wrote: >On Wed, Apr 04, 2012 at 04:24:29PM +0200, Thomas Wolff wrote: >>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. This is fixed in the latest snapshot and in the upcoming release. 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-04-05 15:19 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1268678816.345581.1333548784781.JavaMail.open-xchange@email.1und1.de> 2012-04-04 14:24 ` Re: input delay issues Thomas Wolff 2012-04-04 14:43 ` Christopher Faylor 2012-04-05 15:19 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).