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

Multi-line paste with WSL omits and splices together lines #14736

New Issue
Open
opened 2026-01-31 04:18:08 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 04:18:08 +00:00
Owner
Copy Link

Originally created by @Wainberg on GitHub (Jul 31, 2021).

Windows Terminal version (or Windows build number)

Windows Terminal version 1.9.1942.0, WSL version 1, Windows 10 21H1 Build 19043.985

Other Software

No response

Steps to reproduce

Paste the following 50 lines of text into your bash prompt using Ctrl + Shift + V, with the terminal height set to the default of 30 rows:

line 1
line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
line 12
line 13
line 14
line 15
line 16
line 17
line 18
line 19
line 20
line 21
line 22
line 23
line 24
line 25
line 26
line 27
line 28
line 29
line 30
line 31
line 32
line 33
line 34
line 35
line 36
line 37
line 38
line 39
line 40
line 41
line 42
line 43
line 44
line 45
line 46
line 47
line 48
line 49
line 50

Expected Behavior

No response

Actual Behavior

It only pastes as many lines as the height of the terminal, and then skips everything until the last line. For instance, if I paste into the terminal when it's 30 lines high (the default), it prints line 1 through line 30 and then skips to line 50:

image

If I then maximize, it looks fine... except that line 9 is incorrectly printed as "line 90":

image

and if I then re-minimize, it incorrectly prints line 2 as line 22, line 3 as line 33, ... and line 9 as line 99. There was no line 99 in my original text, so it seems to be splicing together bits of different lines.

image

Interestingly, if I copy-paste the terminal contents into Sublime Text, it pastes the incorrect text, including the line 99 thing:

image

Another test I tried is pasting the original "line 1", "line 2", ... "line 50" text when the terminal is 30 lines tall, and then expanding it to 32 lines. Now it prints lines 31 and 32 before skipping to line 50. It also incorrectly prints line 8 as "line 80" and line 9 as "line 90" - the 0 is probably coming from "line 10" immediately below:

image

Originally created by @Wainberg on GitHub (Jul 31, 2021). ### Windows Terminal version (or Windows build number) Windows Terminal version 1.9.1942.0, WSL version 1, Windows 10 21H1 Build 19043.985 ### Other Software _No response_ ### Steps to reproduce Paste the following 50 lines of text into your bash prompt using Ctrl + Shift + V, with the terminal height set to the default of 30 rows: ``` line 1 line 2 line 3 line 4 line 5 line 6 line 7 line 8 line 9 line 10 line 11 line 12 line 13 line 14 line 15 line 16 line 17 line 18 line 19 line 20 line 21 line 22 line 23 line 24 line 25 line 26 line 27 line 28 line 29 line 30 line 31 line 32 line 33 line 34 line 35 line 36 line 37 line 38 line 39 line 40 line 41 line 42 line 43 line 44 line 45 line 46 line 47 line 48 line 49 line 50 ``` ### Expected Behavior _No response_ ### Actual Behavior It only pastes as many lines as the height of the terminal, and then skips everything until the last line. For instance, if I paste into the terminal when it's 30 lines high (the default), it prints line 1 through line 30 and then skips to line 50: ![image](https://user-images.githubusercontent.com/7513967/127721415-fa5aa608-9bcc-44ed-be72-81a68f297510.png) If I then maximize, it looks fine... except that line 9 is incorrectly printed as "line 90": ![image](https://user-images.githubusercontent.com/7513967/127721559-b76b31af-4e08-4d6b-b79c-25589a28ed97.png) and if I then re-minimize, it incorrectly prints line 2 as line 22, line 3 as line 33, ... and line 9 as line 99. There was no line 99 in my original text, so it seems to be splicing together bits of different lines. ![image](https://user-images.githubusercontent.com/7513967/127721618-7aba3fd7-3e55-4516-afe4-dd9997a25396.png) Interestingly, if I copy-paste the terminal contents into Sublime Text, it pastes the incorrect text, including the line 99 thing: ![image](https://user-images.githubusercontent.com/7513967/127721694-57ce93a8-ed4e-4fa2-93c5-19a9d1b1677d.png) Another test I tried is pasting the original "line 1", "line 2", ... "line 50" text when the terminal is 30 lines tall, and then expanding it to 32 lines. Now it prints lines 31 and 32 before skipping to line 50. It also incorrectly prints line 8 as "line 80" and line 9 as "line 90" - the 0 is probably coming from "line 10" immediately below: ![image](https://user-images.githubusercontent.com/7513967/127721961-4b29fab3-3781-427f-8deb-67e3320f3fe9.png)
claunia commented 2026-01-31 04:18:09 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 2, 2021):

Curious. This is maybe related to #5800, or #6901. I'll tag it up as related, to try and untangle what's really at fault here. Thanks for the repro case!

@zadjii-msft commented on GitHub (Aug 2, 2021): Curious. This is maybe related to #5800, or #6901. I'll tag it up as related, to try and untangle what's really at fault here. Thanks for the repro case!
claunia commented 2026-01-31 04:18:10 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 5, 2021):

This looks like an implementation detail of how bash handles an input buffer that's taller than the screen. Here's what it does in xterm:

image

Given that it's the reference implementation, and that we're acting similar to it... i'm inclined to say "bash is doing it wrong."

However, I'll check what VT is coming out on resize to make sure that the issue where 9 becomes 90 (etc.) is also expected.

@DHowett commented on GitHub (Aug 5, 2021): This looks like an implementation detail of how bash handles an input buffer that's taller than the screen. Here's what it does in xterm: ![image](https://user-images.githubusercontent.com/189190/128411843-b9a1f673-279c-453c-a551-b736d41e5bd8.png) Given that it's the reference implementation, and that we're acting similar to it... i'm inclined to say "bash is doing it wrong." However, I'll check what VT is coming out on resize to make sure that the issue where 9 becomes 90 (etc.) is also expected.
claunia commented 2026-01-31 04:18:10 +00:00
Author
Owner
Copy Link

@inphobia commented on GitHub (Aug 10, 2021):

This looks like an implementation detail of how bash handles an input buffer that's taller than the screen

migth or might not be relevant, but my findings in #6901 were all done with zsh, not bash.

@inphobia commented on GitHub (Aug 10, 2021): > This looks like an implementation detail of how bash handles an input buffer that's taller than the screen migth or might not be relevant, but my findings in #6901 were all done with zsh, not bash.
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 Area-Input Issue-Bug Priority-2 Product-Terminal Resolution-External
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#14736
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?