select() fails on multi-byte input in cygwin console (since 1.7.10)
Wed Dec 10 07:03:00 GMT 2014
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
(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
after you have *released* the key (looking carefully before the keyboard
Now, when you press a mouse key, the whole sequence appears, with the
mouse wheel scrolling or focus reports (click out then into the console
window) - here
only the first byte is seen until any other input.
> 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
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
I'm afraid it's not simply the console code. I suspect there is some
between console code and Windows events (and I'm not familiar with
I could at best try to find out which of the changes 1.7.9->1.7.10 made
the issue appear.
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprÃ¼ft.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin