This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
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