[ANNOUNCEMENT] Updated: libreadline7-7.0.3-3

Eric Blake eblake@redhat.com
Fri Jul 28 23:55:00 GMT 2017

On 07/28/2017 07:09 AM, Steven Penny wrote:
> On Fri, 28 Jul 2017 06:41:08, Eric Blake wrote:
>> As in /etc/defaults/Cygwin.bat installed by the base-files package?
> As in "C:\cygwin64\Cygwin.bat" that can be found after a regular install of
> Cygwin

Oh, that one doesn't show up under 'cygcheck -p', so it must be created
by setup.exe.

>> It's short:
>> @echo off
>> setlocal enableextensions
>> set TERM=3D
>> cd /d "%~dp0bin" && .\bash --login -i
> Uh, no? Mine looks like this. Again this is the file installed by
> Cygwin, not
> something I have home brewed:
>    @echo off
>    C:
>    chdir C:\cygwin64\bin
>    bash --login -i

Odd that there are two different flavors of the file - but the point
remains that they are doing pretty much the same thing: starting bash.

>> so if you are already in a cmd window, and typing cygwin.bat, then it is
>> the same as if you are directly starting bash from cmd.
> I am not doing this, I am just using Windows explorer to go to
> "C:\cygwin64",
> then double clicking "Cygwin.bat"

Yay! That means you ARE running cygwin in a cmd window (and NOT a mintty
window) - because that's what double-clicking the .bat file does.  Okay,
I'm a bit more confident that I'm at least in the right environment to
reproduce what you are seeing.

I still think the desktop shortcut pointing to mintty is a nicer
environment than running bash in a cmd window, but that's orthogonal.

>> By the way, I didn't know cygwin.bat was still around (I had to go
>> hunting for it).  Ages ago, that use to be the target of the shortcut
>> installed to the desktop, but we switched quite a while ago to having
>> the target point directly to mintty instead of the .bat file (since
>> mintty is a LOT friendlier than running inside cmd).
> I dont want mintty. As you know mintty adds another "layer" to the
> situation,
> another process. If I was using mintty I would not have discovered this
> problem
> in the first place. Some might say good, but no. It is important that even
> launching Cygwin via Cygwin.bat/bash.exe works in a sane manner; and
> that it not
> sacrifice features that even cmd.exe has, which is the current situation.

I agree that running under cmd should work as best as possible, but cmd
is severely limited, and interactions with mintty get debugged faster
than interactions with cmd.

>> Also, what does 'chcp.com' say prior to you executing cygwin.bat
> Prior to "Cygwin.bat", it says 65001, because I feel that is the proper
> default
> for Windows. I set it like this:
>    REG ADD 'HKCU\Console' /v CodePage /t REG_DWORD /d 65001 /f

Ah, so I see 437 by default on my setup, but you've made a system-wide
tweak.  So PART of your issue is that cygwin1.dll might not be paying
attention to your tweak (since the code page DOES affect what alt-
sequences produce when using cmd) - it is highly possible that
cygwin1.dll still needs improvements with regards to translating alt-
sequences according to the current code page (when codepage 437 is
active, alt-[1-9]-NNN works according to the current page; while
alt-0-NNN according to Unicode code point - insofar as the code point is
representable in the current code page).  But my other mail pointed out
that when using a plain cmd window (no cygwin in the mix), I'm not
entirely sure how the alt- sequences work for code page 65001 in the
first place, to know if cygwin is even interpreting things correctly.

>> are you then trying to call chcp.com WHILE bash is running? I have no
>> idea if
>> cygwin is even aware/amenable of live code page changes while running
>> inside a
>> cmd window
> Yes, However I do not think this is germain to the conversation, as I
> have found
> you can change it "live" without issue.

Well, it IS relevant if it means that live changes to the code page
SHOULD affect cygwin1.dll behavior dynamically.  It's not relevant to
whether bash itself is mishandling alt- sequences in general (my
debugging so far says that with code page 437, typing alt-1-4-8 produces
\xc3\xb6 (the correct UTF-8 encoding of ö, which is decimal code 148 in
code-page 437), but that bash's parser loop (in readline) is reading
only one byte at a time, and tries to treat \xc3 as 'meta-n' and
triggers its incremental-search functionality, then treats \xb6 as an
incomplete character to be searched for; rather than realizing that the
two bytes belong together as a multibyte character.  That part of
readline MIGHT be related to using pselect() (where configuring pselect
out of the equation takes a different code path to learn if more data
needs to be read before starting to act on the data).  I still haven't
figured out why readline is breaking the input or how to fix it.

>> Making me chase URLs doesn't help as much as a single mail, with a
>> step-by-step reproduction of what you did vs. what you expected, so that
>> I can refer to a single window rather than multiple browser tabs when
>> trying to follow those same steps.
> Cmon man, give me a break here, I am trying. I have been posting on this
> issue
> for months, and Id rather not keep regurgitation the same stuff over and
> over.

I know, you ARE helping. But I'm also saying that some forms of help are
easier than others ("look at this link" is less helpful than "here are
the steps").  And it doesn't help that my free time for cygwin is sporadic.

> At any rate, here is the text from that link,
>    $ chcp.com 65001
>    Active code page: 65001
> - Alt 148 outputs nothing
> - Alt 0246 outputs nothing

But that's true even in a bare cmd window. So it's hard to say what it
is SUPPOSED to do.  I'm trying to debug bash, not cmd's alt- behavior.

> - Pasting this character does not work

Pasting is different from alt- sequences, but I haven't played with that
yet, because pasting in cmd windows is a pain compared to middle-click
pasting in mintty (get the alt- stuff working first, and the pasting may
magically work).

>    $ chcp.com 437
>    Active code page: 437
> - Alt 148 works
> - Alt 0246 works
> - Pasting works

Wait, it works for you in bash? It wasn't working for me.

> and here is why 65001 is needed at all:
>    $ cat omega.c
>    #include <stdio.h>
>    int main() {
>     printf("Ω\n");

Bad form to assume your compiler is using a particular code set (but
presumably you write that file in a UTF-8 editor); better would be:
printf("\xce\xa9") which is unambiguously the UTF-8 bytes for U+03a9 (or
even "\u03a9", if your C compiler is new enough).

>    }
>    $ x86_64-pc-cygwin-gcc -o cygwin.exe omega.c
>    $ x86_64-w64-mingw32-gcc -o mingw32.exe omega.c
>    $ chcp.com 65001
>    Active code page: 65001
>    $ ./cygwin.exe
>    Ω
>    $ ./mingw32.exe
>    Ω

That makes sense: code page 65001 is the Unicode page, so ideally all
UTF-8 sequences should hit the terminal as their appropriate Unicode glyphs.

>    $ chcp.com 437
>    Active code page: 437
>    $ ./cygwin.exe
>    Ω

Cygwin may be at fault here: it is outputting a Unicode glyph even
though the current code page is not Unicode.  But I'm also not ruling
out weirdness in cmd (it's not open source, so I can't prove who is at
fault, after all).

>    $ ./mingw32.exe
>    Ω

This is the correct two-character (not multi-byte) sequence to output
according to the code page 437 glyph table (in that code page, \xce is
the character u+256C, and \xa9 is the character u+2310).  Spitting out
UTF-8 bytes to a unibyte locale (which is what code page 437 is) is
generally going to produce mojibake.  Which is why using a unibyte
locale is annoying.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20170728/a973f419/attachment.sig>

More information about the Cygwin mailing list