* 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).