select() fails on multi-byte input in cygwin console (since 1.7.10)

Thomas Wolff
Wed Dec 10 07:03:00 GMT 2014

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

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

> Thanks,
> Corinna

Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list