DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 6562ra1x3520440
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 6562ra1x3520440
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=kUkaWnIh
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 254CB4C31817
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1780714415;
	bh=Zv1xQy8pU/BCgimnVKgZ9UmTBilbBiJPk8Tx9lR6Qd0=;
	h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post:
	List-Help:List-Subscribe:From:Reply-To:From;
	b=kUkaWnIhSL2saf1IdT9hNjkj/1guJXLp3oQQ6Lz4+naJpo8E4ldpXIgO3DGfKebI5
	/pQ6PpLkIENkYiSVW1e/fwLxMGwyAfnuVQfwqKDp1nRp2TTQ+2mKKHuuCTlgohbqtl
	tjthVYHSaaMRZGtaL96jm8X63261A6i6afbPXFm4=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org BB04D4BA543C
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org BB04D4BA543C
ARC-Seal:	i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1780714362; cv=pass;
	b=KEiMkmxH189HJr5R4DrrvTVZaImvSenEpeJb0vu5aKkSJo1+pD9CweJ/j9BJcVW1R1h0Na38kFrzEJJp7EEluiW5ExFfMTiPHW3xkrcr2SwHviwe2sxIvTFhseUDU/RTZmDHjslbyQdPgxzvLlp8bCOqrn2kvROtU1Z/hmwC9bo=
ARC-Message-Signature:	i=2; a=rsa-sha256; d=sourceware.org; s=key;
	t=1780714362; c=relaxed/simple;
	bh=Y3zpytzGcO2gD/ECJ6xGhqzsIxELujDqf/yK5El6hkM=;
	h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
	b=DDeryh2+B1tDkCiADtGaMEawQw2KgQYvDle1ovIXI7AmnUkwpVAFCR/l390a7xXbgQTwqBDs4HqCHvCO/UO9u2sF3qXjhsPvvijT8LiofovaaW+VhARkmv59nUJzUBG1hCc8ZLq41Bxdfod8P3ivBTQ0j64FarFAv4daZarY6/s=
ARC-Authentication-Results:	i=2; sourceware.org;
	dkim=pass (2048-bit key, unprotected)
	header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104
	header.b=kXPe1itt
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org BB04D4BA543C
ARC-Seal:	i=1; a=rsa-sha256; t=1780714362; cv=none;
	d=google.com; s=arc-20240605;
	b=AQrk5OkNSSgpgp9JiAuhlfIVTlIIH5TI1EmSAujeqcifLxohj/QtBPUu7f8UpudULA
	NJjnJ9i/A3B6i59c3+xPxSC40WWlat5FQ1uNTQRUYteYmgRP/tvWTxWA2zVsHoBdws7A
	jAhKpxyE9+jrs312GHT6T++jo07Lbzwq+qi7lL0T6nqXffNgmwzJKT1a2qjQNWRnYzFr
	TVmNBTkVqBjCFDyqpfOSMi/jZnySEvS9bYD3RwZYx6Wgby2vHFAHxzoaYaVQ2yuAqmxf
	BViFb4DX+K+ynqLT+yH3JwaUnTsb4q3ntFAjtq2phtjIj2ooYKaNh4To9oiwX7DFGCh/
	7Z+Q==
ARC-Message-Signature:	i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
	s=arc-20240605;
	h=to:subject:message-id:date:from:mime-version:dkim-signature;
	bh=/SiQyxSWOiLcB1h7HriRfElwfpf/hJG3WZ2YSp0Htks=;
	fh=UKNFaOBO97U3RYl3PEse//nArTqr7SLJjCCEBz281Ew=;
	b=ip5/2PwFs6AaRm1+KlfH4Nl+LvrzvkRP/9KQtCwGluZlblQUGeTYwQrcpUoXGsEEjb
	3V1x83Lq5N8I0+JAG3Uac+VRQ34siVay9S1WU/U6AQJH0FAANdoK6VMLVuTqJP/Pc8y7
	mZEAY6eAOzLt7qlFvTVASfYqdChH6m2F1keDFTi9b+/Xp5Piv00gfZjBN/IyJmCdZcwa
	u6nTM2bk9gNSgRZwByNy8Jdrovy3ZT1u6q8xgi0Ro9C8e/eenFYmnkRw4OH4SNdxS+5a
	FSM/Qw7gi/meqgOFcUuPnkYNARDS1POjyAmDcCjmnEVGwD+8C4dchh/xvCXftZB7xtZU
	fecw==; darn=cygwin.com
ARC-Authentication-Results:	i=1; mx.google.com; arc=none
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20251104; t=1780714362; x=1781319162;
	h=to:subject:message-id:date:from:mime-version:x-gm-gg
	:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
	bh=/SiQyxSWOiLcB1h7HriRfElwfpf/hJG3WZ2YSp0Htks=;
	b=c5TGW4N5//V1vD9O3j2LU02y16qu4oxFtM2q4KSx0Nl3j/QLTB9IVzBWfOMdV+0MP4
	bjurkURgp0bM0gI5ZmE+u3by68T3LzZTAGAlwbMT1ujp1Mifqe0lShPalASrfYO3bWDq
	Vo0fZzhtVAA8ef0YVNuKBSIYnMaFLswXwczTVgRkQno8oqbkTvDY4I4awSnUfbj/s6MH
	Ndi9hL65zdhnb4wIHp0xhIcSrQFf4yREEgSv9GGuZ/5N21Cz7llWcBgtl5rAhYY9ppG1
	B5G9XwKhWOmpocotpOkgiLBGqikB9JnGAXIeJBGhqubZjeD6SGq/6wk0fZe1lQo4EQQ3
	6KIw==
X-Gm-Message-State:	AOJu0YwuHQKX83FHA2FyYibJX44eWRnu/OJX/AbkUiVFAQWnLttZ8yV/
	avprlyclMmexkuvclLRFDXiZyFEX6xvI6lDMdsZqEJQhlhI2loFWG/8G1aqI3s+QJDznNzQfcC+
	UmP1Sb1xDSL4ZdN2bZ8FfoN+KYEGy4ifm4nMG
X-Gm-Gg:	Acq92OE5BR0vSqz2G4s3jQEND5z8fRTpy1K4jmK/snXkzF1qSuieEJVz564S2KJ0Ok1
	0hh7RRHwUTjUzzkfCqR+d7WpIurZk2jWcatQVUBUkBwj1DCjw8HOkMovYlvO9g2SdO88jb4v6l7
	oOoocNEDsCKC75vCUavPFSiWRMEf+dRR3hIfgSH0KIgAaS5E93aLiSoYZ8NYuiNS0KB/7ZRoj9P
	xOLhTVyhWrW+CefHGpCnFJ/voD62j1+9vIMAyflF7DF/XSJUgdBJ10dfjWG3npdK89OdEAPCSkr
	lNzLQTngVDiaQzdQ
X-Received:	by 2002:a05:690e:1908:b0:660:5dc3:3fe0 with SMTP id
	956f58d0204a3-66106e0dfacmr5847592d50.14.1780714361930; Fri, 05 Jun 2026
	19:52:41 -0700 (PDT)
MIME-Version:	1.0
Date:	Sat, 6 Jun 2026 11:52:06 +0900
X-Gm-Features:	AVHnY4JLOOEZ37k71XzUr6v7oemycvTLxaFdBfvfmMW7d6JlM-H7tfJHHKN9SMc
Message-ID:	<CAFLRLk_wsepYvsbrGWk142pvRg2JbdsEvpjVaMBKtbeK=eXuhA@mail.gmail.com>
Subject:	Cygwin-3.6.9: pcon: CPR responses are broken when a non-Cygwin
	executable starts
To:	cygwin AT cygwin DOT com
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Koichi Murase via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Koichi Murase <myoga DOT murase AT gmail DOT com>
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

Let me report an issue where the terminal response CPR to the DSR(6)
request is somehow transformed by the pseudo-console handling in the
middle, when a non-Cygwin executable is executed before the response
is read by Bash.

Cygwin version:

I can reproduce it with the current release, Cygwin 3.6.9-1, and also
with the latest test release 3.7.0-0.501.gd06ec7.  The problem doesn't
reproduce in Cygwin 3.6.7-1, which means that the issue started to
happen in either 3.6.8 or 3.6.9.  I haven't tested 3.6.8 because it is
not found in the list of Cygwin Installer (setup-x86_64.exe), and the
Cygwin Snapshots page seems to have been shut down.

The transformation of the response seems to happen somewhere between
the terminal and the shell.  I confirmed that the terminal sends the
correct data, and the shell receives the broken sequence. In addition,
the issue doesn't happen when I set `CYGWIN=disable_pcon', so I
believe it is related to some handling of pseudo-console.

Repeat-By (expected result):

The following may look like an unrealistic use case, but this is a
reduced case of some complex settings in a realistic situation. We
first demonstrate the expected behavior, using a Cygwin executable.
After that, we consider the broken case with a non-Cygwin executable.

1. Build a Cygwin executable.  To demonstrate the issue, we consider
the simplest program,  `int main() {}',. which immediately exits. If
one hasn't yet installed a compiler, `gcc' or `clang', one can select
and install `gcc-core' in the Cygwin Installer (setup-x86_64.exe).
Then, one can build a binary at, e.g., ~/a.exe by e.g. the following
command:

$ gcc -xc -o ~/a.exe - <<< 'int main() {}'

In the following steps, we assume that the executable is located at
`~/a.exe'. Please replace that part accordingly when you use another
path for the executable file.

2. Prepare a bashrc:

```
# ~/.bashrc
printf '\e[6n'
~/a.exe
read -r
declare -p REPLY
```

3. Start Cygwin64 Terminal (Mintty) (assuming that your login shell is
set to be Bash).
4. Then, press [Return] on the keyboard to end the input for `read
-r'. Then, the following line is printed:

```
declare -- REPLY=$'\e[1;1R'
```

which is expected. The argument `\e[6n' in the printf in the bashrc is
a terminal control sequence DSR(6) for the request of the current
cursor position in the terminal. The terminal is expected to respond
with CPR in the form `\e[<row>;<col>R'. The above response implies
that the cursor was on the first column on the first line in the
terminal display, which is indeed correct.

Repeat-By (the issue):

Then, let us proceed with the case of the problem.

1. Build a non-Cygwin executable. Actually, the executable can be any
non-Cygwin binary, such as C:\Windows\System32\attrib.exe, but to
illustrate that the issue is simply caused by whether the executable
file is Cygwin or non-Cygwin, let us build a binary consistently with
the previous case. This time, one can install
`mingw64-x86_64-gcc-core' in the Cygwin Installer (setup-x86_64.exe).
Then, one can similarly build a binary using the MinGW version of the
compiler:

$ x86_64-w64-mingw32-gcc -xc -o ~/a.exe - <<< 'int main() {}'

2. We use the same bashrc as the previous case.
3. Start Cygwin64 Terminal (Mintty). Then, even before typing [Return]
from the keyboard, you'll see the following terminal contents:

```
Cdeclare -- REPLY=""

user AT host ~
$ C
```

where a character "C" strays into the command line. The `read -r'
reads an empty string into REPLY.

It is the issue that the shell doesn't receive the expected CPR
response in the form `\e[<row>;<col>R', and instead, receives some
other stuff.

Other observations:

* As I mentioned earlier, the problem doesn't happen when one sets
`CYGWIN=disable_pcon'.
* The issue can also be reproduced by real non-Cygwin executable
files. For example, replacing `a.exe' with `attrib . &>/dev/null' does
not change the problematic behavior.
* The issue does not happen when stdin of the non-Cygwin executable
file is redirected. For example, replacing `~/a.exe' with `~/a.exe <
/dev/null' suppresses the error. On the other hand, redirecting stdout
and stderr (as `~/a.exe &>/dev/null') doesn't solve the problem.

Through trials and errors, I noticed two different cases of broken
responses. One is `\e[[C', and the other is simply `C'. The sequence
`\e[[C' is a representation of the <f3> key in TERM=cygwin, which can
be confirmed by observing the output of

$ TERM=cygwin tput kf3 | cat -v
^[[[C

On the other hand, in some terminals, `\e[1;1R' may be interpreted as
a representation of the <f3> key. This suggests the suspicion that the
pseudo-console handling interprets \e[1;1R as <f3> and then re-encodes
it with a different representation of <f3>, `\e[[C'.  Then, the `\e[['
part may sometimes be even consumed and stripped, which results in the
simple `C'.

Fix:

The pseudo-console handling sitting between the terminal and the
application shouldn't translate a sequence looking like the keyboard
input <f3> to a different representation <f3>.

The CPR response and the terminal sequence for the <f3> key may be
inherently ambiguous (depending on TERM), so the pseudo-console layer
doesn't have a way to judge a sequence to be either CPR or <f3>.  The
only thing the pseudo-console layer can do is to send the sequence
unmodified.

Even if the sequence could be identified as a representation of the
<k3> key, I believe the sequence should not be converted. The terminal
application is supposed to know the representation used by the
terminal through the environment variable TERM or other ways for the
terminal identification, so it doesn't require the translation.
Rather, if the representation is converted, the terminal application
is confused.

--
Koichi

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -