public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* input delay issues
@ 2012-04-02 19:47 Thomas Wolff
  2012-04-02 20:56 ` Christopher Faylor
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Wolff @ 2012-04-02 19:47 UTC (permalink / raw)
  To: cygwin

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.

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] 6+ messages in thread

* Re: input delay issues
  2012-04-02 19:47 input delay issues Thomas Wolff
@ 2012-04-02 20:56 ` Christopher Faylor
  2012-04-02 23:48   ` Adam Puckett
  2012-04-03 19:32   ` Thomas Wolff
  0 siblings, 2 replies; 6+ messages in thread
From: Christopher Faylor @ 2012-04-02 20:56 UTC (permalink / raw)
  To: cygwin

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.

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] 6+ messages in thread

* Re: input delay issues
  2012-04-02 20:56 ` Christopher Faylor
@ 2012-04-02 23:48   ` Adam Puckett
  2012-04-02 23:54     ` Christopher Faylor
  2012-04-03 19:32   ` Thomas Wolff
  1 sibling, 1 reply; 6+ messages in thread
From: Adam Puckett @ 2012-04-02 23:48 UTC (permalink / raw)
  To: cygwin

Christopher Faylor wrote:

>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.
>
>cgf

What if this thread looked for TERM to be "cygwin?"

--
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] 6+ messages in thread

* Re: input delay issues
  2012-04-02 23:48   ` Adam Puckett
@ 2012-04-02 23:54     ` Christopher Faylor
  0 siblings, 0 replies; 6+ messages in thread
From: Christopher Faylor @ 2012-04-02 23:54 UTC (permalink / raw)
  To: cygwin

On Mon, Apr 02, 2012 at 07:48:07PM -0400, Adam Puckett wrote:
>Christopher Faylor wrote:
>>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.
>
>What if this thread looked for TERM to be "cygwin?"

I can't really respond to that since it makes no sense.

If you aren't at least somewhat familiar with Cygwin internals and
Windows consoles then you probably aren't going to have anything useful
to add here.

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] 6+ messages in thread

* Re: input delay issues
  2012-04-02 20:56 ` Christopher Faylor
  2012-04-02 23:48   ` Adam Puckett
@ 2012-04-03 19:32   ` Thomas Wolff
  2012-04-04 14:03     ` Christopher Faylor
  1 sibling, 1 reply; 6+ messages in thread
From: Thomas Wolff @ 2012-04-03 19:32 UTC (permalink / raw)
  To: cygwin

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.
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] 6+ messages in thread

* Re: input delay issues
  2012-04-03 19:32   ` Thomas Wolff
@ 2012-04-04 14:03     ` Christopher Faylor
  0 siblings, 0 replies; 6+ messages in thread
From: Christopher Faylor @ 2012-04-04 14:03 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-04-04 14:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-02 19:47 input delay issues Thomas Wolff
2012-04-02 20:56 ` Christopher Faylor
2012-04-02 23:48   ` Adam Puckett
2012-04-02 23:54     ` Christopher Faylor
2012-04-03 19:32   ` Thomas Wolff
2012-04-04 14:03     ` 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).