DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 658Bq3K9825546
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 658Bq3K9825546
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=Sc9szSza
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 79E2F4C3189F
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1780919522;
	bh=mLhQr93mcgc0t/AWUGGxgmv3YxMRtMo7QEud6vsfWwc=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=Sc9szSzaz9iiFTU1wZeDKTzln8QWYYgtOrT0mbPmhU7GudNOu10LsHedXV+Gb47BX
	92Vfx80wY8TMGLATSg+szldyyGRO6yVYNnRzIVjKZ9VaGbCeSS4cu3dqCVSBOzsqwO
	z/TABpBGNrJNM3ELyk3GWQ6NO3+tEPUzMVJ+aWeg=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org F03384B1970C
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org F03384B1970C
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780919469; cv=none;
	b=vRBiv0jZqkL6mwK0DQKdyBAeyjNZfglmIDWnEHPYUhqTWZNbjpMfT++GpHTiak935YrG4rePwxh6R9Pg9PV9u7JIczrqqed/9F/jNRD0xevXrIMiQGl39s/IEQlbDNzDuYArbZ08nkws//XDxXt3xMs0ajtsu06Uao1ErzefRPU=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1780919469; c=relaxed/simple;
	bh=PH2eYvDSXSoYxyGPq7r+ConYHDtV17j0ESJkUYNMNSM=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=AO3T4Z7kuELWqqg+0tO6CY8SYGMFOSRox88hTeNU6xERY4T3f/6zNfD6mRD3WzmHMe+/PzMk+khw1MMG/EUx7WcKJSXVreA57XkaqOY3ovRiqp3wTSQLVrdiTG0MCnSQVS5J3NAkEWQzzPvNQoaF2WRxjiklYwdK3bYznJINtro=
ARC-Authentication-Results:	i=1; sourceware.org;
	dkim=pass (2048-bit key, unprotected)
	header.d=nifty.ne.jp header.i=@nifty.ne.jp header.a=rsa-sha256
	header.s=default-1th84yt82rvi header.b=ZKzqjtpf
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org F03384B1970C
Date:	Mon, 8 Jun 2026 20:51:01 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: Cygwin-3.6.9: pcon: CPR responses are broken when a non-Cygwin
	executable starts
Message-Id:	<20260608205101.f8196e646a13e4d9386b470e@nifty.ne.jp>
In-Reply-To:	<CAFLRLk_wsepYvsbrGWk142pvRg2JbdsEvpjVaMBKtbeK=eXuhA@mail.gmail.com>
References:	<CAFLRLk_wsepYvsbrGWk142pvRg2JbdsEvpjVaMBKtbeK=eXuhA AT mail DOT gmail DOT com>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version:	1.0
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-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
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:	Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

Hi Koichi,

Thanks for the report. I have taken a look at the issue.

On Sat, 6 Jun 2026 11:52:06 +0900
Koichi Murase wrote:
> 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.

The empty read result is caused by a bug of cygwin, which was
introduced by the commit:

commit a0b38a81b9be482a0058e8f4f5477eeae2f2c012
Author: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Date:   Tue Mar 17 11:33:21 2026 +0900

    Cygwin: pty: Apply line_edit() for transferred input to to_cyg

In this case, the response is without enter key, so the response
is still in the read ahead buffer and is not ready to read.
However, the commit sets event input_available_event even in this
case. 

> 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.

The undesired conversion (CPR to F3 key) is done by pseudo console.
I don't think this is a right conversion, but pseudo console surely
does this. It's not cygwin's fault. However, I found a workaround.
If ENABLE_VIRTUAL_TERMINAL_INPUT is set, the conversion will not be
applied. So, I'll add this flag to console mode when transfering
the input from cyg-pipe to nat-pipe.

I'll submit two patches to cygwin-patches mailing list to solve the
issue.

Please stay tuned.

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

-- 
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 -