select() fails on multi-byte input in cygwin console (since 1.7.10)
Wed Dec 10 12:51:00 GMT 2014
On Dec 10 08:03, Thomas Wolff wrote:
> Hi Corinna,
> Am 09.12.2014 um 12:19 schrieb Corinna Vinschen:
> >Hi Thomas,
> >On Dec 9 08:02, Thomas Wolff wrote:
> >>Calling select() to check whether input from the terminal is available
> >>fails for all but the first byte in the cygwin console if multiple bytes
> >>are entered at once, like function or cursor keys or non-ASCII UTF-8
> >>Actually, the issue is volatile, sometimes it works for characters and
> >>most function keys.
> >>The problem most likely arises with the escape sequences mouse scroll
> >>and window focus out/in (both enabled by the test program).
> >>I tried to use read() with timeout instead, trying various combinations
> >>of tcsetattr setting VMIN/VTIME, fcntl setting O_NONBLOCK, using read()
> >>with buffer length 0, trying to interrupt read() with a timer signal, or
> >>even a combination of setitimer() and siglongjmp().
> >>None of this works.
> >Your STC creates 0s and 1s, and it looks quite normal to me with the
> >latest from CVS. Without a short description I don't know exactly what
> >to look out for. There are lots of 0s, and if I press a cursor key
> >I see three 1s, one for each char of the escape sequence.
> I should have been more precise, and there are actually two slightly
> different effects (I noticed the first after my report): If you press
> a multi-byte key (like ä, €, F1), only the first byte will be seen by
> select() and echoed immediately by the test program. The remaining
> bytes will only appear after you have *released* the key (looking
> carefully before the keyboard auto-repeats...).
Uh, ok, now I saw it.
> Now, when you press a
> mouse key, the whole sequence appears, with the exception of mouse
> wheel scrolling or focus reports (click out then into the console
> window) - here only the first byte is seen until any other input.
I have no mouse wheel (good old 3-button mouse here :)) so I can't test
it, but the effect is clear now.
> >Did you try the latest snapshot or the 1.7.34-002 test release? ...
> Yes, no change. (And yesterday's snapshot mentioned in some other
> thread is not yet visible.)
> >If that doesn't help, would you mind trying to track this down? You're
> >familiar with Cygwin's console code so you might get a clue what's going
> Partially familiar...
> Since mouse escape sequences are all generated
> in the same way but there is a difference among them (the bug
> occurring with mouse scrolling and window focus switching), I'm afraid
> it's not simply the console code. I suspect there is some subtle
> interference between console code and Windows events (and I'm not
> familiar with Windows APIs). I could at best try to find out which of
> the changes 1.7.9->1.7.10 made the issue appear. We'll see...
Sure. The switch from 1.7.9 to 1.7.10 is just long ago. It doesn't
hurt to look, but it might not be that helpful to see the difference,
given the changes to the console code in the meantime.
You could also have a look into the affected select code, which is
basically the function peek_console in select.cc. What I see there is
PeekConsoleInput (h, &irec, 1, &events_read)
checks if any one byte of input is available in the console(*) and
ReadConsoleInput (h, &irec, 1, &events_read);
so apparently it always reads(**) only one byte per select.
Maybe a bit of experimenting here would help?!?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin