Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.1-1, libreadline-devel-7.0.1-1, bash-4.4.5-1

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3057 bytes --]

[again, your email client likes to break threading, so I nearly missed
this one]

On 01/17/2017 06:36 PM, Steven Penny wrote:
> On Mon, 16 Jan 2017 19:32:19, Steven Penny wrote:
>> I did another bisect on the readline-7.0-testing branch and came up with this:
>>     ef27d114778ffef483ed2746603f9487f880edbd is the first bad commit
>>     commit ef27d114778ffef483ed2746603f9487f880edbd
>>     Author: Chet Ramey <chet.ramey@case.edu>
>>     Date:   Thu Jul 9 16:28:21 2015 -0400
>>         readline-7.0-alpha distribution
> 

Are you building readline from source each step of the bisection? And
are you applying all the downstream cygwin patches each build, or just
using the stock upstream sources? (The cygwin patches can be found in
/usr/src if you use setup.exe to download the sources)

> This still works on Linux, even with libreadline7.

Linux doesn't have a cmd.exe.  And in mintty, I'm having no problems
entering extended characters (well, there, ALT-6-6 gives 'B' as in
ASCII, but ALT-2-3-4 gives 'ê' instead of 'Ω', while ALT-+-2-3-4 gives
'Ω', but at least input isn't silently dropped).  So I really think this
is an issue with interacting with the native windows console (which is
cygwin's domain), and not with the input being fed to readline (readline
is reading the terminal presented by cygwin, but it is cygwin that is
interpreting the console's reaction to keypresses in a way that is
converted to what cygwin apps think is a normal terminal).

Another thing I tried: running bash in mintty, this command:
 printf $'\u66\u3a9'
outputs 'fΩ' (correct, since hex 66 is 'f', while decimal 66 is 'B').
But while running bash directly from cmd.exe, the same command results
in 'f\u03A9'.  It's as if bash has determined (from locale?) that the
current character set is not Unicode, and therefore outputs an escape
sequence instead of the UTF-8 sequence.  So next I tried
LANG=en_US.UTF-8. After that, the printf produced the results I got in
mintty, but ALT-2-3-4 caused \316 to be output.

Normally, I _don't_ run anything under cmd.exe (all my use of cygwin is
under mintty), so I need a lot of hand-holding to reproduce anything in
your setup, in particular how you are even getting extended characters
to print (what locales and/or window settings you have to set).

> Chet is refusing to address
> the issue:
> 
> http://lists.gnu.org/archive/html/bug-readline/2017-01/msg00001.html

I didn't even know bug-readline existed (all the readline bug reports
I've seen over the years have been addressed to bug-bash); I'm
subscribed now.  But Chet is right that it is probably a Cygwin problem,
and not a readline problem.

> 
> So it looks like we will need a Cygwin specific patch?

Well, first someone has to get to the real root cause. Since I have been
unable to reproduce it, and I don't have much free time to devote to it,
I don't know when that will be.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]