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

Pasting multiline text within the quotes does not work #18003

New Issue
Closed
opened 2026-01-31 06:00:55 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 06:00:55 +00:00
Owner
Copy Link

Originally created by @AgentMC on GitHub (Jul 22, 2022).

Windows Terminal version

1.13.11431.0

Windows build number

Microsoft Windows [Version 10.0.19043.1826]

Other Software

Powershell 5/7

Steps to reproduce

  1. Open Terminal with Powershell 5 or 7
  2. type $x='' (ending with 2 single quotes)
  3. Move your cursor between the two single quotes
  4. Paste a multiline JSON, e.g.
[
  {
    "partition": 0,
    "offset": 1414225,
    "timestamp": 1641981208266
  }
]

Expected Behavior

The text is pasted between the quotes, that is, where the cursor is. Consequently, the trailing single quote is moved to the last line after the text being pasted. Consequently, the Powershell does not attempt to "execute" JSON.

This behavior is expected as the normal among every single OS and app out there, including consoles, such as CMD.

Actual Behavior

Text is pasted line by line. The first [ is indeed pasted between the quotes but the rest is pasted as a separate commands, which does not work.

Originally created by @AgentMC on GitHub (Jul 22, 2022). ### Windows Terminal version 1.13.11431.0 ### Windows build number Microsoft Windows [Version 10.0.19043.1826] ### Other Software Powershell 5/7 ### Steps to reproduce 1. Open Terminal with Powershell 5 or 7 2. type `$x=''` (ending with 2 single quotes) 3. Move your cursor between the two single quotes 4. Paste a multiline JSON, e.g. ``` [ { "partition": 0, "offset": 1414225, "timestamp": 1641981208266 } ] ``` ### Expected Behavior The text is pasted _between the quotes_, that is, where the cursor is. Consequently, the trailing single quote is moved to the last line after the text being pasted. Consequently, the Powershell does not attempt to "execute" JSON. This behavior is expected as the normal among every single OS and app out there, including consoles, such as CMD. ### Actual Behavior Text is pasted line by line. The first `[` is indeed pasted between the quotes but the rest is pasted as a separate commands, which does not work.
claunia added the Issue-BugResolution-ExternalNeeds-Tag-Fix labels 2026-01-31 06:00:56 +00:00
claunia commented 2026-01-31 06:00:57 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Jul 22, 2022):

The same trouble is in WT preview 1.15.1863.0. In conhost.exe this works without errors. The Get-Clipboard cmdlet also works.
$x = gcb

@237dmitry commented on GitHub (Jul 22, 2022): The same trouble is in WT preview 1.15.1863.0. In conhost.exe this works without errors. The Get-Clipboard cmdlet also works. ```$x = gcb```
claunia commented 2026-01-31 06:00:57 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 22, 2022):

I believe that this is due to.. a number of things.

Foremost, it is that PowerShell does not support bracketed paste mode: https://github.com/PowerShell/PSReadLine/issues/1471

After that, it is that all paste operations in a terminal emulator are, to a rough first approximation, equivalent to "pretend the user typed this stuff in really fast." So really, your clipboard stream is converted into [ enter space space { enter space . . .

PowerShell has special support for what happens when you submit a quoted string without a closing quote; it offers you a continuation prompt:

image

However, that continuation prompt is suppressed when you submit a quoted string with a closing quote even if your cursor is inside the quoted string.

Bracketed paste helps that by telling the shell to treat a section of input as literal and not interpret it until the paste has completed.

At the end of the day, there's two things that you can do. First: help us apply pressure on the PSReadline bracketed paste issue so that PowerShell can grow support for this. Second: consider unbinding Terminal's defaultCtrl+V binding and letting PowerShell handle the clipboard. Third: follow https://github.com/microsoft/terminal/issues/11414 to get updates on a related feature, which would be to let you specify that a right-click sends ^V to PowerShell, which would allow it to handle the clipboard directly.

Thanks, and I'm sorry that's probably not a satisfying answer.

/dup https://github.com/PowerShell/PSReadLine/issues/1471

@DHowett commented on GitHub (Jul 22, 2022): I believe that this is due to.. a number of things. Foremost, it is that PowerShell does not support bracketed paste mode: https://github.com/PowerShell/PSReadLine/issues/1471 After that, it is that all paste operations in a terminal emulator are, to a rough first approximation, equivalent to "pretend the user typed this stuff in really fast." So really, your clipboard stream is converted into `[ enter space space { enter space . . . ` PowerShell has special support for what happens when you submit a quoted string without a closing quote; it offers you a continuation prompt: <img width="201" alt="image" src="https://user-images.githubusercontent.com/189190/180499868-f010b10b-c326-4ca8-86c8-f26a10bacd83.png"> However, that continuation prompt is suppressed when you submit a quoted string with a closing quote _even if your cursor is inside the quoted string._ Bracketed paste helps that by telling the shell to treat a section of input as literal and not interpret it until the paste has completed. At the end of the day, there's two things that you can do. First: help us apply pressure on the PSReadline bracketed paste issue so that PowerShell can grow support for this. Second: consider unbinding Terminal's default<kbd>Ctrl+V</kbd> binding and letting PowerShell handle the clipboard. Third: follow https://github.com/microsoft/terminal/issues/11414 to get updates on a related feature, which would be to let you specify that a right-click sends `^V` to PowerShell, which would allow it to handle the clipboard directly. Thanks, and I'm sorry that's probably not a satisfying answer. /dup https://github.com/PowerShell/PSReadLine/issues/1471
claunia commented 2026-01-31 06:00:57 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 22, 2022):

Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!

@ghost commented on GitHub (Jul 22, 2022): Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!
claunia commented 2026-01-31 06:00:57 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Jul 23, 2022):

PSReadline does not matter. This behavior is only in WT.

@237dmitry commented on GitHub (Jul 23, 2022): PSReadline does not matter. This behavior is only in WT.
claunia commented 2026-01-31 06:00:58 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 25, 2022):

PSReadline does not matter. This behavior is only in WT.

image

@DHowett commented on GitHub (Jul 25, 2022): > PSReadline does not matter. This behavior is only in WT. ![image](https://user-images.githubusercontent.com/189190/180843049-22029947-b84b-4268-a96f-2bf39c0cb486.png)
claunia commented 2026-01-31 06:00:58 +00:00
Author
Owner
Copy Link

@AgentMC commented on GitHub (Jul 25, 2022):

Not for the sake of argument but this gets really confusing.

@DHowett are you saying Windows Command Prompt is broken in Windows 11? Or Notepad? Because this is cmd (conhost) in W10. I am also getting the same when launching directly powershell.exe and pwsh.

image

@AgentMC commented on GitHub (Jul 25, 2022): Not for the sake of argument but this gets really confusing. @DHowett are you saying Windows Command Prompt is broken in Windows 11? Or Notepad? Because this is cmd (conhost) in W10. I am also getting the same when launching directly powershell.exe and pwsh. ![image](https://user-images.githubusercontent.com/11662240/180859437-8e91ef18-7d4d-4799-88a3-ea4746e0f68c.png)
claunia commented 2026-01-31 06:00:58 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 25, 2022):

are you saying Windows Command Prompt is broken in Windows 11? Or Notepad?

Neither!

I think the extra complication here is that PSReadline handles Ctrl+V on its own, and when it handles paste on its own it does the right thing (because it's in control of when it reads the clipboard and where it inserts the input.)

At the end of the day, there's work to be done on PSReadline to converge terminal-driven paste (right-click, Ctrl+Shift+V, and in some configurations Ctrl+V) and shell-driven paste (Ctrl+V in PSReadline, by default).

Until then, our recommendation is to unbind Ctrl+V in your terminal and not use right-click paste. This will only work in PowerShell, since it is the only shell in common use that has its own clipboard handling.

Because this is cmd (conhost) in W10. I am also getting the same when launching directly powershell.exe and pwsh.

(Those are all conhost; cmd is not involved except to launch powershell inside the same conhost window later.) My repro specifically compares Terminal's pasting behavior (right-click, C-S-v) with conhost's (right-click, C-S-v) and avoids PowerShell's internal paste handler.

FWIW: this behavior seems to be highly conserved across different terminal emulators and shells in the absence of bracketed paste. Here are Konsole, Foot and xterm hosting bash.

Screenshot_20220725_144604

When bracketed paste is working, however!:

Screenshot_20220725_144925

@DHowett commented on GitHub (Jul 25, 2022): > are you saying Windows Command Prompt is broken in Windows 11? Or Notepad? Neither! I think the extra complication here is that PSReadline handles <kbd>Ctrl+V</kbd> on its own, and when it handles paste on its own it does the right thing (because it's in control of when it reads the clipboard and where it inserts the input.) At the end of the day, there's work to be done on PSReadline to converge terminal-driven paste (right-click, <kbd>Ctrl+Shift+V</kbd>, and in some configurations <kbd>Ctrl+V</kbd>) and shell-driven paste (<kbd>Ctrl+V</kbd> in PSReadline, by default). Until then, our recommendation is to unbind <kbd>Ctrl+V</kbd> in your terminal and not use right-click paste. This will only work in PowerShell, since it is the only shell in common use that has its own clipboard handling. > Because this is cmd (conhost) in W10. I am also getting the same when launching directly powershell.exe and pwsh. (Those are all conhost; cmd is not involved except to launch powershell inside the same conhost window later.) My repro specifically compares Terminal's pasting behavior (right-click, C-S-v) with conhost's (right-click, C-S-v) and avoids PowerShell's internal paste handler. FWIW: this behavior seems to be highly conserved across different terminal emulators and shells in the absence of bracketed paste. Here are Konsole, Foot and xterm hosting bash. ![Screenshot_20220725_144604](https://user-images.githubusercontent.com/189190/180861882-0f560884-fadf-4bc1-a0f9-a06ffd255585.png) When bracketed paste is working, however!: ![Screenshot_20220725_144925](https://user-images.githubusercontent.com/189190/180862365-b32bdb81-76b7-4b02-bebd-5b316b1fe4fc.png)
claunia commented 2026-01-31 06:00:58 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Jul 26, 2022):

is that so?

Screenshot 2022-07-26 150816

The pasted lines are automatically placed in the continuation prompt. In WT error.

Screenshot 2022-07-26 151459

@237dmitry commented on GitHub (Jul 26, 2022): > is that so? ![Screenshot 2022-07-26 150816](https://user-images.githubusercontent.com/78153320/181002333-2e75005c-7b19-4155-886f-8a3dc7325dca.png) The pasted lines are automatically placed in the continuation prompt. In WT error. ![Screenshot 2022-07-26 151459](https://user-images.githubusercontent.com/78153320/181003458-5258e081-33c3-49f6-8c7f-34bf923a8293.png)
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 Needs-Tag-Fix 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#18003
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?