tmux exception in windows terminal

[zhang-stephen]

Windows Terminal version (or Windows build number)

windows 10.0.183631743, terminal 1.10.1933.0 preview

Other Software

openSUSE tumbleweed 202108xx in virtual box
SSH for windows 8.1p1
tmux 3.2a
Z-Shell 5.8

Steps to reproduce

start the openSUSE VM, connect to it in windows terminal via ssh, and run tmux in windows terminal, you will see the ^[[>0;10;1c; as mentioned in tmux: #2844.

I have tried PuTTY and MobaXterm 20, this issue seems only be reproduced in windows terminal. and the maintainer of tmux thought it's a bug/incorrect behavior from terminal, could you help to investigate this problem?

Expected Behavior

the ^[[>0;10;1c; should not be printed on screen.

Actual Behavior

the ^[[>0;10;1c; printed on screen.

[elsaco]

From tmux manual:

 escape-time time
         Set the time in milliseconds for which tmux waits after an escape is input to determine if it is part of
         a function or meta key sequences.  The default is 500 milliseconds.

@Stark-Zhang is the issue still present if you add "set -sg escape-time 10" to your .tmux.conf to increase the time from default?

@Stark-Zhang is this happening when connecting to a remote system also?

[zadjii-msft]

Does this repro if you use a vintage console window (i.e conhost.exe) to run ssh.exe?

If you use ssh from a WSL distro instead of ssh.exe, does the issue still happen? (Just trying to remove variables here - Terminal running ssh.exe connected to a machine running tmux is a lot of moving parts. )

[zhang-stephen]

Does this repro if you use a vintage console window (i.e conhost.exe) to run ssh.exe?

If you use ssh from a WSL distro instead of ssh.exe, does the issue still happen? (Just trying to remove variables here - Terminal running ssh.exe connected to a machine running tmux is a lot of moving parts. )

1. I tried run ssh.exe in PowerShell 7 and this issue reproduced.
2. It's not reproduced in WSL Ubuntu 20.04.3

[zhang-stephen]

From tmux manual:

 escape-time time
         Set the time in milliseconds for which tmux waits after an escape is input to determine if it is part of
         a function or meta key sequences.  The default is 500 milliseconds.

@Stark-Zhang is the issue still present if you add "set -sg escape-time 10" to your .tmux.conf to increase the time from default?

@Stark-Zhang is this happening when connecting to a remote system also?

1. this would reproduce if configured as you said.
2. this didn't reproduce on other remote system, such as CentOS or RHEL, even keep the default configuration.

[iBug]

I can reproduce this on a remote Ubuntu host over OpenSSH. On tmux startup there's the strange 0;10;1c printed on tmux. This doesn't happen with conhost.exe (running ssh.exe <remote> from CMD window). Ubuntu 20.04 (tmux 3.0a) and 22.04 (tmux 3.2a) are both affected.

[zadjii-msft]

@gurka in #12752

Note: this works OK with Powershell instead of Windows Terminal. Haven't verified any other terminal emulators, but I'm pretty sure that it works OK in PuTTY as well.

There are few bug tickets in other projects, like microsoft/WSL#5931, but in my scenario it seems Windows Terminal is the culprit - hence the ticket here. Also for me this happens every time while in those other tickets it seems to happen randomly.

TERM is xterm-256colors before starting tmux and tmux-256colors after starting tmux, both when using Windows Terminal and Powershell.

And like in those other tickets I'm also using set -s escape-time 0 in my .tmux.conf. Setting this to 50 solves the issue.

[j4james]

In tmux/tmux#2844, @nicm suggested that this was a terminal bug because tmux was receiving a "doubled DA response", but that's not what's actually happening here.

The first response you see is just the input buffer echoing whatever it receives while the system is busy. Once control is returned to the shell, that input is eventually read and interpreted as key presses, and that's when the content is echoed a second time by the shell. In short, it's a single response, but echoed by two different parts of the system.

You should be able to reproduce the same behavior in any other terminal with a simple statement like this:

printf "\e[>c"; sleep 1

So if the "double response" is the only bug we're tracking here, I don't think there's anything for us to fix.

[nicm]

Sorry deleted my previous comment by mistake...

I don't think this is the case, tmux logs show this coming in twice from the pty:

1629709496.462244 /dev/pts/0: wrote 77 bytes (of 77)
1629709496.462555 /dev/pts/0: keys are 10 (\033[>0;10;1c)
1629709496.486818 /dev/pts/0: keys are 10 (\033[>0;10;1c)

It does send it to the shell and the shell does print it, but this is expected because it treats the second response as normal key presses.

You can see this in the strace log as well, note I have also shown when tmux turns off ECHO and calls tcflush. The \033[>c is somewhere in among a few writes (I have shown the first):

17740 18:12:19.686376 ioctl(5, SNDCTL_TMR_START or TCSETS, {c_iflags=0x1, c_oflags=0, c_cflags=0xbd, c_lflags=0x20, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=0, c_cc="\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"}) = 0
17740 18:12:19.687797 ioctl(5, TCFLSH, TCIOFLUSH) = 0
...
17740 18:12:19.699877 writev(5, [{iov_base="\33[?25l\33[K\r\n\33[K\r\n\33[K\r\n\33[K\r\n\33[K\r\n\33"..., iov_len=393}], 1 <unfinished ...>
...
17740 18:12:19.723468 readv(5,  <unfinished ...>
17740 18:12:19.723853 <... readv resumed>[{iov_base="\33[>0;10;", iov_len=8}], 1) = 8
17740 18:12:19.726362 readv(5,  <unfinished ...>
17740 18:12:19.727418 <... readv resumed>[{iov_base="1c\33[>0;", iov_len=7}], 1) = 7
17740 18:12:19.729552 readv(5,  <unfinished ...>
17740 18:12:19.729717 <... readv resumed>[{iov_base="10;1c", iov_len=5}], 1) = 5

[j4james]

I don't think this is the case, tmux logs show this coming in twice from the pty:

@nicm That may be the case, but Windows Terminal is not just returning two responses - something else must be triggering that. And all the manual tests you were doing while cat-ing the logs seem to confirm that. For example, look at the output here: tmux/tmux#2844 (comment)

You said that was the response being returned twice, but the first one (and the second partial bit after the prompt) are just what was written to the screen in the original log. The only reason you didn't see that on iTerm2 was because your screen size was different, and it couldn't fit the full height of the page. Note how you weren't seeing the first prompt line either (the one with the timestamp 05:04:57 PM).

It also doesn't help that you were using cat to view the response in all your tests, because that just confused things for the poor user. When he pressed Return it would echo the response that was received, but the Windows Terminal DA2 response is \033[>0;10;1c, which is also technically a DA2 request! So every Return would trigger another response.

It occurred to me, though, that there might be something else in the pipeline that is doing the same sort of thing, i.e. echoing the DA2 response without escaping control characters. Possibly the ssh client? That might explain why you see two responses despite sending only one request.

[nicm]

I can only comment on what is happening with tmux and it is receiving two responses, this logging:

1629709496.462555 /dev/pts/0: keys are 10 (\033[>0;10;1c)
1629709496.486818 /dev/pts/0: keys are 10 (\033[>0;10;1c)

Means that tmux is reading from the pty and getting the same response twice. strace shows the same. There is no confusion with what is echoed or not echoed by the receiving process here.

This does not seem to be a simple matter of one response being echoed by the tty layer and then by the process that receives it, as in your example shell command. tmux has turned the ECHO flag off before it emits the DA request sequence.

You are exactly right that something must be triggering it, but we were unable to work out what that was even when sending the same output as tmux.

[jackschedel]

Also having this issue.

[chrispy-snps]

Same issue. Glad to see it is already filed!

For now, setting escape-time to 10 is a good workaround.

[devnakx]

I have the same issue, and it happens in almost all of my tmux sessions. I have also tried switching to other terminal programs (PuTTY or Termius) and didn't encounter this problem, but I still think Windows Terminal is the best to use.
I also tried setting escape-time, but it didn't work.