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