starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Console filters out bracketed paste input codes when virtual terminal input is disabled #22437

New Issue
Open
opened 2026-01-31 08:13:12 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 08:13:12 +00:00
Owner
Copy Link

Originally created by @jart on GitHub (Oct 22, 2024).

Originally assigned to: @DHowett on GitHub.

Windows Terminal version

1.22.2702.0

Windows build number

10

Other Software

This issue applies broadly to all WIN32 software. In my case, I happen to be working on Cosmopolitan Libc.

Steps to reproduce

  1. Use SetConsoleMode() to disable the ENABLE_VIRTUAL_TERMINAL_INPUT flag on GetStdHandle(STD_INPUT_HANDLE).
  2. Use SetConsoleMode() to enable the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag on GetStdHandle(STD_OUTPUT_HANDLE).
  3. Write the string "\033[?2004h" to standard output, to enable bracketed paste mode.
  4. Press ctrl-shift-v or shift-ins to paste text with multiple lines into the terminal.
  5. Reading from standard input will give you the pasted text (but it's supposed to surround the paste with "\033[200~" and "\033[201~")

If you're a Cosmopolitan Libc fan and have cosmocc installed from our GitHub releases page, then here's a simple program that can reproduce this without needing to write any WIN32 code.

void Write(const char *s) {
  write(1, s, strlen(s));
}

int main(int argc, char *argv[]) {
  Write("\033[?2004h");
  char buf[512];
  int rc = read(0, buf, 512);
  Write("\033[?2004l");
  printf("got %`'.*s\n", rc, buf);
}

See also https://github.com/jart/cosmopolitan/blob/master/libc/calls/read-nt.c if you're curious about our termios driver.

Expected Behavior

If I enable bracketed paste mode on the terminal, then I believe it should insert the "\033[200~" and "\033[201~" ANSI codes into the paste, even if ENABLE_VIRTUAL_TERMINAL_INPUT is disabled. Cosmopolitan Libc needs this. Cosmo is similar to Cygwin in that it implements POSIX on Windows. For example, common utilities like bash and emacs can be compiled with cosmo libc and then run in the command prompt. I've been very successful making this work well. This bug is the one problem I can't solve unless Microsoft fixes things. It is impossible to work around this issue.

Why is that? Cosmopolitan Libc always wants a virtual ANSI style Linux-like terminal. To do that, we always enable ENABLE_VIRTUAL_TERMINAL_PROCESSING on standard output. Virtual terminal output works fantastically with your tools. However Cosmo never uses ENABLE_VIRTUAL_TERMINAL_INPUT because it isn't very good. Virtual terminal input is a toy feature that makes important use cases impossible, such as polling console input. Cosmopolitan Libc always uses ReadConsoleInput() and GetNumberOfConsoleInputEvents() to read console input and then manually translates INPUT_RECORD to ANSI codes and implements things like canonical mode line editing because there's no other way.

However there's one and only one occasion where I actually DO want WIN32 to inject \033[200~ and \033[201~ ANSI codes into my input, and that's for bracketed paste mode. Windows should either do this, or it should generate INPUT_RECORD events that tell me where the paste begins and ends. But Windows does neither and that's a huge painful issue for me.

Actual Behavior

Windows makes it impossible to obtain the the \033[200~ and \033[201~ ANSI codes that tell me where pasted text begins and ends, unless ENABLE_VIRTUAL_TERMINAL_INPUT is enabled. It's not possible for me to enable this flag, because that flag is problematic and removes win32 capabilities when it's enabled, such as the ability to poll console input. If I've put the terminal into bracketed paste mode by writing the virtual ANSI sequences to the output handle, which does have virtual mode enabled, then the console should not filter out and remove those ANSI codes when they get sent to my input. The ENABLE_VIRTUAL_TERMINAL_INPUT flag presence should be ignored in this specific case.

Originally created by @jart on GitHub (Oct 22, 2024). Originally assigned to: @DHowett on GitHub. ### Windows Terminal version 1.22.2702.0 ### Windows build number 10 ### Other Software This issue applies broadly to all WIN32 software. In my case, I happen to be working on Cosmopolitan Libc. ### Steps to reproduce 1. Use SetConsoleMode() to *disable* the `ENABLE_VIRTUAL_TERMINAL_INPUT` flag on `GetStdHandle(STD_INPUT_HANDLE)`. 2. Use SetConsoleMode() to *enable* the `ENABLE_VIRTUAL_TERMINAL_PROCESSING` flag on `GetStdHandle(STD_OUTPUT_HANDLE)`. 3. Write the string `"\033[?2004h"` to standard output, to enable bracketed paste mode. 4. Press ctrl-shift-v or shift-ins to paste text with multiple lines into the terminal. 5. Reading from standard input will give you the pasted text (but it's supposed to surround the paste with `"\033[200~"` and `"\033[201~"`) If you're a Cosmopolitan Libc fan and have `cosmocc` installed from our GitHub releases page, then here's a simple program that can reproduce this without needing to write any WIN32 code. ```c void Write(const char *s) { write(1, s, strlen(s)); } int main(int argc, char *argv[]) { Write("\033[?2004h"); char buf[512]; int rc = read(0, buf, 512); Write("\033[?2004l"); printf("got %`'.*s\n", rc, buf); } ``` See also https://github.com/jart/cosmopolitan/blob/master/libc/calls/read-nt.c if you're curious about our termios driver. ### Expected Behavior If I enable bracketed paste mode on the terminal, then I believe it should insert the `"\033[200~"` and `"\033[201~"` ANSI codes into the paste, even if `ENABLE_VIRTUAL_TERMINAL_INPUT` is disabled. Cosmopolitan Libc needs this. Cosmo is similar to Cygwin in that it implements POSIX on Windows. For example, common utilities like bash and emacs can be compiled with cosmo libc and then run in the command prompt. I've been very successful making this work well. This bug is the one problem I can't solve unless Microsoft fixes things. It is impossible to work around this issue. Why is that? Cosmopolitan Libc always wants a virtual ANSI style Linux-like terminal. To do that, we always enable `ENABLE_VIRTUAL_TERMINAL_PROCESSING` on standard output. Virtual terminal output works fantastically with your tools. However Cosmo *never* uses `ENABLE_VIRTUAL_TERMINAL_INPUT` because it isn't very good. Virtual terminal input is a toy feature that makes important use cases impossible, such as polling console input. Cosmopolitan Libc *always* uses ReadConsoleInput() and GetNumberOfConsoleInputEvents() to read console input and then manually translates `INPUT_RECORD` to ANSI codes and implements things like canonical mode line editing because there's no other way. However there's one and only one occasion where I actually DO want WIN32 to inject `\033[200~` and `\033[201~` ANSI codes into my input, and that's for bracketed paste mode. Windows should either do this, or it should generate `INPUT_RECORD` events that tell me where the paste begins and ends. But Windows does neither and that's a huge painful issue for me. ### Actual Behavior Windows makes it impossible to obtain the the `\033[200~` and `\033[201~` ANSI codes that tell me where pasted text begins and ends, unless `ENABLE_VIRTUAL_TERMINAL_INPUT` is enabled. It's not possible for me to enable this flag, because that flag is problematic and removes win32 capabilities when it's enabled, such as the ability to poll console input. If I've put the terminal into bracketed paste mode by writing the virtual ANSI sequences to the output handle, which _does_ have virtual mode enabled, then the console should not filter out and remove those ANSI codes when they get sent to my input. The `ENABLE_VIRTUAL_TERMINAL_INPUT` flag presence should be ignored in this specific case.
claunia added the Issue-QuestionIssue-BugNeeds-Tag-FixResolution-Answered labels 2026-01-31 08:13:13 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Issue-Question Needs-Tag-Fix Resolution-Answered
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22437
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?