Pasted text includes CRLF pairs where unneeded

[d-bingham]

Multiline text pasted from the clipboard includes CRLF pairs in all cases; this is inappropriate for "Unix-space" sessions, such as WSL.

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.145]
Windows Terminal version (if applicable): 71e19cd82528d66a0a7867cbed85990cfc1685f1

Steps to reproduce

Select multiline text in Terminal. Copy it (via right-click, ostensibly) Paste it (again via right-click)

Expected behavior

When pasting into a Unix-space session -- such as WSL -- pasted text should have a reasonable set of line-ending characters.

Actual behavior

Line endings are "doubled" on text paste to Unix-space sessions.

[d-bingham]

[DHowett-MSFT]

This is now the master issue for line feeds on copy/paste. We need a holistic solution that addresses this ("...includes too many line breaks") and #1073 ("... doesn't include line breaks"). :grin:

[conioh]

@DHowett-MSFT @d-bingham The description talks about WSL, but my issue (#1073) happened with no WSL involvement. It's indeed tricky to reproduce (which I noticed after seeing your comments) but happened without WSL.

[DHowett-MSFT]

Indeed. This is more likely related to the console's output mode and what was written to the screen and how it was written instead of any particular tool.

[conioh]

So PR #1094 won't fix it. Either said PR doesn't close this issue or #1073 isn't a duplicate of this issue.

[DHowett-MSFT]

PR #1094 doesn't fix both issues, but we believe that:

We need a holistic solution that addresses this ("...includes too many line breaks") and #1073 ("... doesn't include line breaks").

And this is valuable feedback for 1094 :smile:

[conioh]

Maybe I'm missing something - I admit that I don't know how all this GitHub thing works - but it says above that:

It makes it sound as if once #1094 is approved and merged this issue will be close automatically, and if I understand correctly you agree that it shouldn't.

[d-bingham]

I'm not sure there's really a "holistic" solution here, as @conioh's issue in #1073 is that the text copied to the clipboard doesn't include line breaks, and #1094 fixes a problem with pasted text having CRLFs when LFs are appropriate.

[DHowett-MSFT]

Oh, I see: I got my copies and pastes mixed up. Thanks!

[ivan-section-io]

For Unix/WSL I believe this should be CRLFs to CRs, and not CRLFs to LFs re: https://github.com/microsoft/terminal/pull/1094#issuecomment-498967181

[sandric]

Sorry to bother, but is there at least any workaround (makes it pretty unusable)? I mean in emacs I can redefine pasting function, is there some piping commands reading clipboard I can run from bash to read clipboard with no doubled newlines?

[sandric]

Ok, I'm not sure if thats the place for it to live, but if anyone struggles with it, here's mine workaround using autohotkey program:

<^t::
  Var := Clipboard
  Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n")
  MouseClick, right
return

Now, by pressing LCtrl + t I get normal clipboard output with no doubled newlines, if anyone struggles - workaround for now.

[alexjmoore]

Just wondering if there was any update? I see the latest 0.3 preview didn't address this yet.

[FlipperPA]

Plus one on this bug fix. In Sublime Text 3 on Windows, I can copy this following text (which I'm pasting correctly here):

import pyautogui
from time import sleep

for x in range(1, 1000):
    print(x)

I can also paste it to Notepad, PuTTy, or any number of other programs successfully.

When I right-click to paste it into WSL-2 Ubuntu 18.04 emacs, it doubles carriage returns:

The same double-carriage return behavior occurs when pasting to nano or vim. And when I paste it to WSL-2 cmd:

Thanks for all your efforts on bringing these features to Windows. It is looking incredibly promising as the development environment of choice moving forward, but we'll have to polish some chrome with issues like these.

[FlipperPA]

Just to follow up, this is occurring both in WSL-1 and WSL-2, as another data point.

[JCMais]

With nano this seems worse, because looks like it starts to replace the current content on the file, right below the pasting point.

[genio]

Please fix this. I cannot explain how frustrating this bug is.

[dquist]

Appreciate all the hard work on the terminal, I'm using it for my daily work but this one is particularly frustrating. Is there any workaround?

[ilirb]

I agree this is currently the most frustrating issue with Windows Terminal - WSL

Ok, I'm not sure if thats the place for it to live, but if anyone struggles with it, here's mine workaround using autohotkey program:

<^t::
  Var := Clipboard
  Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n")
  MouseClick, right
return

Now, by pressing LCtrl + t I get normal clipboard output with no doubled newlines, if anyone struggles - workaround for now.

Thanks for this, adjusted a bit to be able to use Ctrl + Shift + V while in WindowsTerminal, to not interfere with other apps

#if WinActive("ahk_exe WindowsTerminal.exe")
    ^+v::
        Var := Clipboard
        Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n")
        MouseClick, right
        return
#if

[CoskunSunali]

There is also another problem where we lose new lines. I don't know if the two might be related.

52

[gitfool]

ConEmu gets this right. I'm reluctant to switch to Microsoft Terminal until this is working; functional copy paste from Windows to Linux and vice versa is crucial!

[FingerlessGlov3s]

I'm getting this issue, now its happening on bash.exe as well as the new terminal on 1909. Only happens for me when I scroll down on nano. using page down.

How's this BUG not been fixed yet?

I was using bash.exe on 1809, and it worked fine. I thought I'd update to 1909, but now my copy n paste is broken for WSL, I'll have to use putty again now.

More detail: You nano a file in WSL, press page down, select and copy few lines of code. You then press return few times and then paste it in. Most return lines are ignored and line ending are not honoured so you get will window width worth of spaces as well as no return line.

Not sure if its a WSL issue or the new terminal. Looking more towards WSL.

[dquist]

How's this BUG not been fixed yet?

Windows Terminal is still in public preview.

[FingerlessGlov3s]

That it is 😉

Isn't the idea of the preview to get feedback and bugs for the app?

[tejasvi]

As of now, is there any workaround while pasting in vim?

[FingerlessGlov3s]

As of now, is there any workaround while pasting in vim?

You can use Xmobaterm to use wsl and that doesn't have the issue.

[JCMais]

Thank you everyone!

Glad to see this finally fixed, it was one of the major pain points while using the new Terminal

[erwa]

Is this fix available in any released preview version of Terminal? It doesn't appear to be in v0.6.2951.0.

[zadjii-msft]

@erwa not yet. v0.6.2951.0 was the "1910" Terminal milestone, and this is fixed for the "1911" milestone. It will be in the next released preview version of the Terminal, sometime later in November.

[erwa]

Gotcha, thanks for the ETA, Mike. I eagerly await the next preview release :).

[ghost]

:tada:This issue was addressed in #3449, which has now been successfully released as Windows Terminal Preview v0.7.3291.0.:tada:

Handy links:

• Release Notes
• Store Download

[erwa]

YESS!! Finally!! I can confirm this issue is fixed in the new preview release. Thank you for fixing this!

[erwa]

One thing I prefer about using the Windows Terminal over the Ubuntu Shell is Windows Terminal has tabs support built-in whereas the Ubuntu Shell does not (I end up using tmux instead).

[paul-michalik]

To be honest I am running into these issues since update to 0.10.781.0.

[DHowett-MSFT]

Commenting on a closed issue is not a very good way to get help. Would you mind putting together a more robust bug report so that we can try to reproduce it?

[paul-michalik]

@DHowett-MSFT Yep, will do. Although, I am having a hard time to navigate around all the issues which somehow look to be related to copy-pasting from (1) terminal to terminal (2) from an application to terminal. Maybe someone from the team should look over it and aggregate everything into one?

[ThomasLachaux]

I have the same problem @paul-michalik encounters When I copy a content that can't fit my window such as an ssh public key on another terminal or even an application like notepad, newlines are inserted where it shouldn't.

I am also an the version 0.10.781.0

[DHowett-MSFT]

You're hitting #5113, which is fixed pending release.