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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
