On 2017-07-31 14:01, Corinna Vinschen wrote:
> On Jul 31 14:36, David Macek wrote:
>> On 31. 7. 2017 11:48, Corinna Vinschen wrote:
>>> Well, it works for me.  I tested this in tcsh, bash and od on
>>> Windows 10.
>> I tested on Windows 2012 R2 (8.1 equivalent) and I can confirm
>> Steven's findings.  Tried with an older installation and then once
>> more after a complete update (`uname -a`s below).
>> - CYGWIN_NT-6.3 computername 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
>> - CYGWIN_NT-6.3 computername 2.8.2(0.313/5/3) 2017-07-12 10:58 x86_64 Cygwin
>>>> - Alt 148 outputs nothing
>>>> - Alt 0246 outputs nothing
>>>> - Pasting this character does not work
>> I ran Cygwin from a clean command window (`cmd /d`) using `chcp ...`
>> and `bin\bash -li`.  The ö's don't appear in bash with CP 65001. Other
>> combinations (bash with CP 437, cmd with either CP) allow ö's to
>> appear.
> Sidenote:
>   If I start just `bash' directly from a cmd window I get weird output
>   like
>     (arg: 6)
>   after lifting my finger from the ALT key.  I can not reproduce it 
>   starting bash as login shell via `bash -l' from cmd or by running
>   Cygwin.bat.  Or, FWIW, when running bash from tcsh.
>   I wonder if that's some missing readline initialization but I'm far from
>   a bash/readline expert.
> Now, Windows 7.
> Sidenote:
>   On W7 the raster font can get you into trouble.  The Window function
>   WriteConsoleW fails with error 31, ERROR_GEN_FAILURE, when trying to
>   output the 'ö' character while the codepage is set to 65001.  That
>   doesn't happen on W10, nor on W7 using Consolas or Lucida fonts.
> Further debugging shows that Alt-Numpad doesn't work on Windows 7
> because the OS doesn't return the required information.
> Huh?  Why then does it look like only bash is affected?
> Other tools, including tcsh, just read from the console, which means,
> only calling ReadConsoleInput under Cygwin's hood.  Readline on the
> other hand, uses select.  Select in turn uses the Windows function
> PeekConsoleInput.
> And as far as I can tell, PeekConsoleInput has a bug in terms of CP
> 65001 on W7.  After lifting the left ALT key, PeekConsoleInput reads an
> input event for the key up event.  If this is the end of a Alt-Numpad
> sequence, the event contains the resulting unicode character.  But not
> so if the codepage is 65001.  In this case the returned unicode
> character has the value 0.  And a subsequent call to ReadConsoleInput
> will also get a unicode char value of 0.
> As far as I can see there's no way around this, unless readline
> stops using select and just reads the input as it comes along.
> I'm just not sure this is worth it.
>> Try the legacy console (conhost v1), if you haven't already.  Maybe it
>> will show the same behavior even on Windows 10.
> I'm using the Windows console by starting "cmd".  I don't know if
> there's another console version available or how to start it.

Cmd/System menu/Properties|Defaults/"Command Prompt"|Console Window Properties
dialogue/Options tab/[ ] Use legacy console (requires relaunch) checkbox at 

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Reply via email to