terminal
terminal copied to clipboard
microsoft
Spurious OSC 11 command ends up writing to terminal or even executing as commands when opening vim
Windows Terminal version
1.23.10732.0
Windows build number
10.0.26100.3476
Other Software
I have an issue with 11;rgb:1e1e/1e1e/1e1e;1R sometimes appearing. It's infrequent (once or twice a day). It can happen either when I ctrl-C to cancel a running script, or when launching neovim. The former is no big deal, it just appears as text at my prompt that I can delete. But if it happens when launching vim the effect is to overwrite one character with the letter g (and leave :1e1e/1e1e/1e1e in my command history). This can be incredibly frustrating/damaging if I don't notice at the time.
I think this is an issue with Windows Terminal. I've moved over from PuTTy and never experienced it there.
If it's not a bug per-se, any pointers anyone can give me to fix this would be hugely appreciated!
Steps to reproduce
Open a file in neovim
Expected Behavior
The file opens, unedited
Actual Behavior
The file opens, and a single character will be replaced by a g. Only very occasionally, maybe one in 100 attempts.
Thanks for reporting!
It looks like this might be a /duplicate of #18004, and may be remediated by changing the escape dwell time.
You can try setting that back to a more sensible value and see if it makes any difference, i.e. add something like set -sg escape-time 500 in your .tmux.conf file.
The proximal root cause is that vim is requesting a terminal cursor color report. It's weird to me that they're dropping it on the floor when it finally comes back to them...
Can you grab a log via the debug tap?
Trying now. As I mentioned it only happens occasionally, and easy to miss even when it does. 🤞
So it's not just vim. I have a startup script in my .bashrc that outputs a couple of log files, uptime information and duf. If I hit ctrl-C while the log files are churning out to the screen, it reliably aborts when duf runs (but before duf outputs anything).
my command prompt ends up with 11;rgb:1e1e/1e1e/1e1e;1R
I ran it a few times and got different post-PS1 debug tap outputs:
␛]11;rgb:1e1e/1e1e/1e1e␛\␛[46;1R␛[67;46;3;0;8;1_␇11;rgb:1e1e/1e1e/1e1e␇;1R␛[17;29;0;0;0;1_
␇11;rgb:1e1e/1e1e/1e1e␇;1R␛[67;46;3;0;8;1_␛[17;29;0;0;0;1_
␛]11;rgb:1e1e/1e1e/1e1e␛\␛[46;1R␛[17;29;0;0;0;1_␇11;rgb:1e1e/1e1e/1e1e␇;1R
Not sure if that's of any help to you 🤷♂️
I'd love to see a full debug tap log if possible. Somebody is requesting the color report and ignoring it, after all... :)
The hallmark to look for is ␛]11;? in white (whereas red is responses and input 🙂)
␛[38;5;208muptime␣/␣df␛[0m␍␊
15:37:49␣up␣30␣days,␣␣7:26,␣␣1␣user,␣␣load␣average:␣0.47,␣0.31,␣0.37␍␊
␍␊
␛]11;?␛\␛[6n␍␊
␛]0;root@web1:/var/www/sites␇␛[?2004h␍␍␊
␛[38;5;208;49m␛[48;5;208;38;5;0mroot␛[38;5;208;49m␛[38;5;15;49m␛[38;5;39;49m␛[48;5;39;38;5;0m15:37:49␛[38;5;39;49m␛[38;5;15;49m␛[38;5;9;49m␛[48;5;9;38;5;0m/var/www/sites␛[38;5;9;49m␛[38;5;15;49m␣␣␛]11;rgb:1e1e/1e1e/1e1e␛\␛[46;1R␇11;rgb:1e1e/1e1e/1e1e␇;1
Is this enough? That's all white, other than the ␛]11;rgb:1e1e/1e1e/1e1e␛\␛[46;1R towards the end which is red.
As you can see I have a tarty PS1, but it's all properly escaped and I don't believe it should cause issues.
This is my PS1, if you think I'm wrong and it's relevant:
\n\[\033[38;5;208;49m\]\[\033[48;5;208;38;5;0m\]\u\[\033[38;5;208;49m\]\[\033[38;5;15;49m\]\[\033[38;5;39;49m\]\[\033[48;5;39;38;5;0m\]\t\[\033[38;5;39;49m\]\[\033[38;5;15;49m\]\[\033[38;5;9;49m\]\[\033[48;5;9;38;5;0m\]\w\[\033[38;5;9;49m\]\[\033[38;5;15;49m\]
Weird! There's definitely somebody requesting a foreground color report right before your prompt but after the application output...
In /this/ instance, I think that "somebody" is duf. If I comment duf out of my startup script, ctrl-C just dumps me to an empty prompt, every time. If I have duf in the script, ctrl-C dumps me (at the point duf is called) to the prompt with the OSC weirdness.
So, if this was my only issue, I could just remove duf from my startup script.
But the infinitely more pressing issue, is these characters being input to neovim once every couple of days or so. You can imagine how frustrating it is when a single letter of code somewhere in your file gets overwritten with a g, and you don't notice!
Presumably the problem anyway isn't WHO'S requesting the fg color report, but how WT handles that. I've tried going back to PuTTy for a few days, and the issue does not seem to happen in PuTTy, so either they're handling the report better, or maybe they just ignore it and never respond. I'm ok with either 😁
If I have duf in the script, ctrl-C dumps me (at the point duf is called) to the prompt with the OSC weirdness.
This is between you and duf. They (more specifically the termenv library that they use) are sending an OSC 11 query to determine the terminal background color, so they can select an appropriate theme to match that. You're assumedly then aborting the app with Ctrl+C before it has had a chance to read the response. It's possible there may be a way for them to shutdown more gracefully when you do that, but that's something best discussed with them.
the infinitely more pressing issue, is these characters being input to neovim
I think neovim does have an escape timeout similar to tmux, so that might be a factor, but I can't see how any of these query responses would then end up overwriting your buffer even if the escape did timeout. It might be something specific to your configuration, but I don't know enough about neovim to know if that's a reasonable hypothesis. You could try starting it with --clean for a while to see if that helps.
Otherwise, if you manage to capture a log from the debug tap when the problem actually occurs, that might help determine where it's going wrong.
the issue does not seem to happen in PuTTy
PuTTY doesn't support the XTerm palette sequences (it uses a completely different system), so that's likely why it doesn't have the same problem. Strangely it does actually support OSC 4 queries, but you can't set the palette with OSC 4, and the OSC 10+ sequences have no effect at all.
I don't believe anything in my config is causing it per se, but I don't doubt that it's probably a race condition kicked off by, well, something in my config. The fact that it happens so infrequently doesn't help. I suspect its maybe more prone to occurrence when my internet connection is being spotty, so I'm going to have a play with clumsy in a few days when I get a chance to try to make it more repeatable.
@downhiller I forgot to mention, if it's timing related, you should be able to reproduce the issue more easily using something like trickly/tritty, which will allow you to simulate a very slow connection. For example, you can start a shell at 57600 baud with tritty -b 57600,
(Please ignore the trailing sequences showing the window is focused in or out)
Could reproduce with 1.22.11141.0, every time I attach to an existing tmux session.
@zent1n0 If you're using tmux, that's issue #18004, and you can usually fix the problem by adjusting the tmux escape-time option to something like 500.
@downhiller Did you try it with wsl? I mean, run ssh.exe in a wsl instance.
If I run run or attench tmux by ssh.exe with wsl, it just works well.
