Pasting multiline text within the quotes does not work

[AgentMC]

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.

[237dmitry]

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

[DHowett]

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

Foremost, it is that PowerShell does not support bracketed paste mode: PowerShell/PSReadLine#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:

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 #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 PowerShell/PSReadLine#1471

[ghost]

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!

[237dmitry]

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

[DHowett]

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

[AgentMC]

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.

[DHowett]

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.

When bracketed paste is working, however!:

[237dmitry]

is that so?

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