X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; q=dns; s=default; b=TUVr
	DH9ULgrYfeo6U33L/YcgcNr11lts/N9jRnu0wzPW8O35/EHHJ9ckjw3INj6/Pyap
	NvDskHszQvwZhiZOzKTREBqkl1W4Qst+Pqml4cNle1wvYwTx5vMKhVYM/bqmK4Ow
	AZtedM2oxaevNq2XIJ2vu1i809z6NCIOvAwAN+U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; s=default; bh=g0EiI22ndz
	6uoRj1MeXEIzFQUA0=; b=yjEurwdHi2IwtPhdHb+KD25C8W/W9ZRL2OZYO3mMJh
	01Vg8Bf7H4/HimURF+b/kH9hGfkeLwD5ghX9GjvkMUNZM4A5O96dw2NHWzAt3ufY
	wTj1LmWy2+aKCuiAaTebMclvzRaK2YPBIdP8KAdYhJtwfIqfTZV4aL1imOSDw1OX
	c=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=interactive, stepped, cfd, replay
X-HELO: mx1.redhat.com
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 257B09D767
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eblake AT redhat DOT com
Subject: Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
To: cygwin AT cygwin DOT com
References: <bb08ea5a-82f4-a586-fca5-79c4a27743ac AT redhat DOT com> <58f1a28e DOT 0a2c9d0a DOT f2ec DOT 8160 AT mx DOT google DOT com> <5dbbf0e4-6374-a9bb-21e5-dd5537e0e19a AT redhat DOT com>
From: Eric Blake <eblake AT redhat DOT com>
Openpgp: url=http://people.redhat.com/eblake/eblake.gpg
Message-ID: <fa8fcc71-5ff5-0cc1-e3ed-f7fece08ae08@redhat.com>
Date: Thu, 27 Jul 2017 13:37:51 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <5dbbf0e4-6374-a9bb-21e5-dd5537e0e19a@redhat.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FJ5JwGR83mQ7Kw45Hl9uFvrU6NrMtDqrS"
X-IsSubscribed: yes

--FJ5JwGR83mQ7Kw45Hl9uFvrU6NrMtDqrS
Content-Type: multipart/mixed; boundary="aCmxE8AicQDmtLDJb8meUTwK9Ub2H9vJL";
 protected-headers="v1"
From: Eric Blake <eblake AT redhat DOT com>
To: cygwin AT cygwin DOT com
Message-ID: <fa8fcc71-5ff5-0cc1-e3ed-f7fece08ae08 AT redhat DOT com>
Subject: Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
References: <bb08ea5a-82f4-a586-fca5-79c4a27743ac AT redhat DOT com>
 <58f1a28e DOT 0a2c9d0a DOT f2ec DOT 8160 AT mx DOT google DOT com>
 <5dbbf0e4-6374-a9bb-21e5-dd5537e0e19a AT redhat DOT com>
In-Reply-To: <5dbbf0e4-6374-a9bb-21e5-dd5537e0e19a AT redhat DOT com>


--aCmxE8AicQDmtLDJb8meUTwK9Ub2H9vJL
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 07/27/2017 12:08 PM, Eric Blake wrote:

> So I'm back to cmd to try and debug things.  Next, I tried:
>=20
> c:\cygwin\bin> .\dash
> <alt-num2-num3-num4>
>=20
> and again got =CE=A9; pressing <enter> complains that ./dash: 1: =CE=A9: =
not found

To double check things, I started .\dash, typed 'echo $$', then in a
second terminal, typed 'gdb --pid XXX' with the dash pid.

(gdb) b read
(gdb) b select
(gdb) c

then in the first window, typed <a><enter> to get dash back to its input
loop

and the second window hit a breakpoint in read.  But that didn't get me
very far:

Thread 1 hit Breakpoint 1, read (fd=3D0, ptr=3D0x41b540 <basebuf>, len=3D10=
24)
    at /usr/src/debug/cygwin-2.8.2-1/winsup/cygwin/syscalls.cc:1118
1118    {
(gdb) fin
Run till exit from #0  read (fd=3D0, ptr=3D0x41b540 <basebuf>, len=3D1024)
    at /usr/src/debug/cygwin-2.8.2-1/winsup/cygwin/syscalls.cc:1118
[New Thread 628.0x70c]

readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)

Urgh - gdb uses readline, so debugging readline with gdb may prove
harder than planned if I don't time things right.  A second time around,
and instead of using fin, I stepped through:

1118   {
(gdb) n
...
(gdb) n
1139         cfd->read (ptr, len);
(gdb) n
[New Thread 736.0x960]

at the point of the new thread, I typed <alt-num2-num3-num4><enter> in
the first terminal, which let the read return, and the buffer contents
are correct:

1140         res =3D len;
(gdb) p len
$1 =3D 3
(gdb) p/x ((char*)ptr)[0]
$2 =3D 0xce
(gdb) p/x ((char*)ptr)[1]
$3 =3D 0xa9
(gdb) p ((char*)ptr)[2]
$4 =3D '\n'

so whatever dash did, it read a solid block of input from the terminal;
from there, I quit debugging - obviously dash is not doing things
piecemeal, and manages to replay the same output as it just read in
input (when you aren't trying hard to be interactive, life is easy).

>=20
> However, when I try:
>=20
> c:\cygwin\bin> .\bash --norc
> <alt-num2-num3-num4>
>=20
> the display shows :\251

Repeating the gdb attach trick, I'm able to catch bash at this
breakpoint, even without hitting <enter>, just by typing <a>:

Thread 1 hit Breakpoint 1, read (fd=3D0, ptr=3D0x28c013, len=3D1)
    at /usr/src/debug/cygwin-2.8.2-1/winsup/cygwin/syscalls.cc:1118

Notice a difference?  dash had the terminal set up in line-oriented
mode, and blindly reads until EOL or until len=3D1024 is exhausted; bash
has the terminal set up in byte-oriented mode, and is only reading len=3D1
at a time.  So when entering a UTF-8 character to dash, the whole
character lands in the buffer at once, while under bash (presumably, as
I haven't debugged that far yet), bash must reconstruct the Unicode
characters from the individual bytes.

Stepping through the breakpoints on <alt-num2-num3-num4> sees 0xce on
the first read, and 0xa9 on the second.  But, in between the two read
breakpoints, the first terminal displayed ':'.  So the input is still
making it correctly INTO readline; but being munged on the way to
output; and it very much looks like readline's fault rather than
cygwin's.  I'm still trying to put breakpoints in the right places (the
call stack at read() points to rl_getc(), from rl_read_key(), from
readline_internal_char()...), but this is at least to let you know how
I'm tackling the issue, in case it helps someone else spot a solution
faster than me by starting from the same information.

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


--aCmxE8AicQDmtLDJb8meUTwK9Ub2H9vJL--

--FJ5JwGR83mQ7Kw45Hl9uFvrU6NrMtDqrS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAll6Mv8ACgkQp6FrSiUn
Q2oHPgf/fEfog2adNpqosKrabS7d8wQNs3DyxT8mLo0vto3oD2gm5M1ru1nGDIAR
YhvsYvPEsCDcWQ4gBh7AskHmOjLHSWx1sbjoDgftiqEOBHw+5YDzBYY1FkIJZ2Zh
ukqskIWwkmIoCiyHrWpDpA3o/Rli16G5V9msASWHq2BJPRItMdPeP3STh6gavSf3
aKMn6cUBpelW1qlwBvEIyzwdm04zaP5vgYQx36Uwc1P1ZfBMb80Bz3BWmUy3X+m1
K1NKh3ubqL72yRhvGJUJ6PWh1f+7Wy2eEFYXVweDvPClsdJAKHa7q4qfTJ9aYWJO
bO6RwfzzAM037SteJkMzig0dlotdHQ==
=w74+
-----END PGP SIGNATURE-----

--FJ5JwGR83mQ7Kw45Hl9uFvrU6NrMtDqrS--