When Copying, Line Wrapped Text Is Inconsistently Broken Into Multiple Lines #9603

claunia commented

@zadjii-msft commented on GitHub (Jul 13, 2020):

Does this repro with an ssh from within WSL as well, or does it only repro with ssh.exe?

@zadjii-msft commented on GitHub (Jul 13, 2020): Does this repro with an `ssh` from within WSL as well, or does it only repro with `ssh.exe`?

claunia commented

@ghost commented on GitHub (Jul 13, 2020):

I've seen it directly in WSL, SSH from inside WSL, and most consistently from ssh.exe to a Linux host. The first two can be hit or miss in reproducing the bug. Even with the most consistent method I posted above it doesn't happen every time. But I did find that in a instance of the Windows Terminal where it happens it will happen consistently but closing out completely and relaunching can sometimes fix the behavior.

@ghost commented on GitHub (Jul 13, 2020): I've seen it directly in WSL, SSH from inside WSL, and most consistently from ssh.exe to a Linux host. The first two can be hit or miss in reproducing the bug. Even with the most consistent method I posted above it doesn't happen every time. But I did find that in a instance of the Windows Terminal where it happens it will happen consistently but closing out completely and relaunching can sometimes fix the behavior.

claunia commented

@garyo commented on GitHub (Jul 15, 2020):

Happens to me too. Inconsistent; I can't detect a pattern so far.

@garyo commented on GitHub (Jul 15, 2020): Happens to me too. Inconsistent; I can't detect a pattern so far.

claunia commented

@zadjii-msft commented on GitHub (Jul 16, 2020):

Alright well, I could have sworn there was a dupe for the newer version of this, but I cannot find it. This is now the thread. I'm gonna link this up to #5800.

Unfortunately without a consistent repro I'm not sure how we'll be able to investigate this, but hopefully by the end of #5800, then this will just go away on it's own.

@zadjii-msft commented on GitHub (Jul 16, 2020): Alright well, I could have sworn there was a dupe for the newer version of this, but I cannot find it. _This is now the thread_. I'm gonna link this up to #5800. Unfortunately without a consistent repro I'm not sure how we'll be able to investigate this, but hopefully by the end of #5800, then this will just go away on it's own.

claunia commented

@vadimkantorov commented on GitHub (Aug 25, 2020):

Also hit by this (in context of copy-pasting large commands):

@vadimkantorov commented on GitHub (Aug 25, 2020): Also hit by this (in context of copy-pasting large commands): ![image](https://user-images.githubusercontent.com/1041752/91170547-59605a80-e6d9-11ea-8013-7f7accc0ca7e.png) ![image](https://user-images.githubusercontent.com/1041752/91170573-611fff00-e6d9-11ea-8a65-34afa9255f1e.png)

claunia commented

@zadjii-msft commented on GitHub (Aug 25, 2020):

@vadimkantorov do you have a consistent repro for how to get the Terminal into this state?

@zadjii-msft commented on GitHub (Aug 25, 2020): @vadimkantorov do you have a consistent repro for how to get the Terminal into this state?

claunia commented

@vadimkantorov commented on GitHub (Aug 25, 2020):

Unfortunately not. But I have this tab opened. If you can suggest how to dump some diagnostics info without restarting terminal, I can do that

@vadimkantorov commented on GitHub (Aug 25, 2020): Unfortunately not. But I have this tab opened. If you can suggest how to dump some diagnostics info without restarting terminal, I can do that

claunia commented

@zadjii-msft commented on GitHub (Aug 25, 2020):

@vadimkantorov Unfortunately there's not really a good way to do that with the Terminal at the moment. If we did have a dump of both the windowsterminal.exe and the openconsole.exe (for that tab), we could maybe try to draw some conclusions about what was wrong based off the state in the Terminal and the VtEngine, but there might not a good way to investigate without a live repro.

There's also a good number of changes coming to this area as a part of #5800, so a part of me expects this issue to either go away as a part of that, or be much easier to repro.

@zadjii-msft commented on GitHub (Aug 25, 2020): @vadimkantorov Unfortunately there's not really a good way to do that with the Terminal at the moment. If we did have a dump of both the `windowsterminal.exe` and the `openconsole.exe` (for that tab), we could _maybe_ try to draw some conclusions about what was wrong based off the state in the Terminal and the VtEngine, but there might not a good way to investigate without a live repro. There's also a good number of changes coming to this area as a part of #5800, so a part of me expects this issue to either go away as a part of that, or be much easier to repro.

claunia commented

@vadimkantorov commented on GitHub (Aug 25, 2020):

I can do a memory dump. I'll send it to you! Thanks for looking into this.

@vadimkantorov commented on GitHub (Aug 25, 2020): I can do a memory dump. I'll send it to you! Thanks for looking into this.

claunia commented

@atwok commented on GitHub (Oct 28, 2020):

Running emacs in terminal mode over SSH. I see this every time cut and paste into a split windows.

Is this the same issue?

@atwok commented on GitHub (Oct 28, 2020): Running emacs in terminal mode over SSH. I see this every time cut and paste into a split windows. Is this the same issue? ![image](https://user-images.githubusercontent.com/26091250/97462086-c334f480-1914-11eb-85cc-21437739064a.png)

claunia commented

@alvaro-gh commented on GitHub (Nov 13, 2020):

Running into the same, SSH to a bastion host, then SSH to a Cisco device, running a show running-config, copy with Ctrl+Shift+C and then pasting with Ctrl+Shift+V.

Edit: the running-config command generates a lot of text so it requires scrolling in order to copy.

Edit 2: so much for me in Windows, going back to Linux until this is fixed.

@alvaro-gh commented on GitHub (Nov 13, 2020): Running into the same, SSH to a bastion host, then SSH to a Cisco device, running a `show running-config`, copy with Ctrl+Shift+C and then pasting with Ctrl+Shift+V. ![terminal](https://user-images.githubusercontent.com/3970003/99110542-4dde4a80-25c9-11eb-89bc-4b50325b217b.JPG) Edit: the running-config command generates a lot of text so it requires scrolling in order to copy. Edit 2: so much for me in Windows, going back to Linux until this is fixed.

claunia commented

@alvaro-gh commented on GitHub (Mar 4, 2021):

I hope this is not spam for everyone subscribed but, wasn't this fixed by #9034? I can no longer reproduce the bad pasting.

@alvaro-gh commented on GitHub (Mar 4, 2021): I hope this is not spam for everyone subscribed but, wasn't this fixed by #9034? I can no longer reproduce the bad pasting.

claunia commented

@zadjii-msft commented on GitHub (Mar 4, 2021):

The bad pasting might be "fixed", but the real problem here is that there's some inexplicable case where ConPTY hard line breaks a line when it really shouldn't be. Or at least, that's what I'm using this issue to track.

@zadjii-msft commented on GitHub (Mar 4, 2021): The bad pasting might be "fixed", but the real problem here is that there's some inexplicable case where ConPTY hard line breaks a line when it really shouldn't be. Or at least, that's what I'm using this issue to track.

claunia commented

@ivanpu commented on GitHub (Apr 28, 2021):

Maybe will be helpful for investigation:
I now had this with a tab split into 4 panes (2 horizontally, then each split into 2 vertically), and wanted to copy-paste a command from one pane (using copyOnSelect) to another (using right click).
It has obviously inserted a spurious new line character in the command:

Version: 1.7.1033.0

Edit: the shell is Cmder in all panes

@ivanpu commented on GitHub (Apr 28, 2021): Maybe will be helpful for investigation: I now had this with a tab split into 4 panes (2 horizontally, then each split into 2 vertically), and wanted to copy-paste a command from one pane (using copyOnSelect) to another (using right click). It has obviously inserted a spurious new line character in the command: ![image](https://user-images.githubusercontent.com/2607888/116451752-9337c100-a865-11eb-9dcc-915a2b26544c.png) Version: 1.7.1033.0 Edit: the shell is Cmder in all panes

claunia commented

@inphobia commented on GitHub (Jul 29, 2021):

i'm not sure if this is related, but i can reproduce the line break thing quite easily.

let's get the details out of the way first

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.19043.0 Microsoft Windows NT 10.0.19043.0

Windows Terminal
Version: 1.9.1942.0
(also tested & reproduced with 1.10.1933.0)

what is is exactly i can reproduce

pasting anything over 500 characters (found this number in another issue, but seems to be correct) will make the pasted text remove/add new lines and paste blocks randomly through each other. the exact location where these incorrect characters get inserted seems mostly random. pasting the same text in the same vi session sometimes appear at the same place, sometimes not. this problem only manifest when pasting into a cygwin terminal, when you copy text from a cygwin window running in windows terminal and paste in another application (either a wsl2 instance in another tab of the same terminal, or in notepad) the text pastes just fine.

there are/were 2 profiles i could reproduce this:

by using zsh from cygwin in windows terminal (or bash). just updated everthing cygwin related to be sure but have seen the issue for several months.
when using psreadline 2.0.0beta2 with powershell 5.1.19041.1023 (no longer have the powershell error message, seem to recall it saying something like System.ArgumentOutOfRangeException: The value must be greater than or equal to zero and less than the console's buffer size in that dimension. and then giving a negative value for either cursor position or something)

i could not (or can't anymore with the versions i'm running now) reproduce this with:

debian or opensuse 15.2 running from windows terminal - wsl2
opensuse 15.0 running from windows terminal - wsl1
powershell 5.1 with psreadline 2.1 running from windows terminal
zsh/vi running from cygwin's native mintty.exe console

how to reproduce

in a cygwin tab paste any text longer as 500 chars... that's it

TERM setting doesn't matter, tried several options
editor doesn't seem to matter. have it in vi, nano, and even with cat <<EOF
ssh to a remote system from the cygwin tab does not fix the issue, same paste problems will persist.
can be reproduced with default windows terminal settings (well, you'll need to add a cygwin profile)
cygwin's zsh must be started from windows terminal. everything works fine when running from mintty.
running git for windows might also have this issue since it uses cygwin underneath.

the following did not matter

copying/pasting in the same cygwin tab. when you paste, problem manifests.
copying in 1 cygwin tab, pasting in a second tab. when you paste, problem manifests.
copying from notepad. when you paste, problem manifests.
copy method: mouse select, ctrl+c, whatever. when you paste, problem manifests.
paste method: shift+insert, right mouse button or paste from the command palette. when you paste, problem manifests.
when copying with mouse, mouse position doesn't matter. you can either nicely start from the beginning of the line and stop at the last character several lines down, or just start & stop wherever you want. when you paste, problem manifests.

why not just stop using zsh/cygwin 😄 ?

habbit, have been using it for 10+years
powershell is great, but i like zsh better for cli work.
wsl2 doesn't play nice with windows always on vpn for my setup
and a host of other semi technical/semi personal reasons

and now for some files.

input text. copied from notepad via ctrl+c

                  GNU GENERAL PUBLIC LICENSE
                     Version 3, 29 June 2007

Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

                          Preamble

The GNU General Public License is a free, copyleft license for
software and other kinds of works.

The licenses for most software and other practical works are designed
to take away your freedom to share and change the works.  By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users.  We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors.  You can apply it to
your programs, too.

When we speak of free software, we are referring to freedom, not
price.  Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights.  Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received.  You must make sure that they, too, receive
or can get the source code.  And you must show them these terms so they
know their rights.

Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.

For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software.  For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.

pasted text in windows terminal. pasted in vi using shift+insert
my settings.json (but also tried with a non modified - other as adding the cygwin profile - settings file in terminal 1.10.1933.0)
settings.json.txt

@inphobia commented on GitHub (Jul 29, 2021): i'm not sure if this is related, but i can reproduce the line break thing quite easily. ### let's get the details out of the way first ``` Platform ServicePack Version VersionString -------- ----------- ------- ------------- Win32NT 10.0.19043.0 Microsoft Windows NT 10.0.19043.0 Windows Terminal Version: 1.9.1942.0 (also tested & reproduced with 1.10.1933.0) ``` ### what is is exactly i can reproduce pasting anything over 500 characters (found this number in another issue, but seems to be correct) will make the pasted text remove/add new lines and paste blocks randomly through each other. the exact location where these incorrect characters get inserted seems mostly random. pasting the same text in the same vi session sometimes appear at the same place, sometimes not. this problem only manifest when pasting into a cygwin terminal, when you copy text from a cygwin window running in windows terminal and paste in another application (either a wsl2 instance in another tab of the same terminal, or in notepad) the text pastes just fine. #### there are/were 2 profiles i could reproduce this: 1. by using zsh from cygwin in windows terminal (or bash). just updated everthing cygwin related to be sure but have seen the issue for several months. 2. when using psreadline 2.0.0beta2 with powershell 5.1.19041.1023 (no longer have the powershell error message, seem to recall it saying something like `System.ArgumentOutOfRangeException: The value must be greater than or equal to zero and less than the console's buffer size in that dimension.` and then giving a negative value for either cursor position or something) #### i could not (or can't anymore with the versions i'm running now) reproduce this with: 1. debian or opensuse 15.2 running from windows terminal - wsl2 2. opensuse 15.0 running from windows terminal - wsl1 3. powershell 5.1 with psreadline 2.1 running from windows terminal 4. zsh/vi running from cygwin's native mintty.exe console ### how to reproduce in a cygwin tab paste any text longer as 500 chars... that's it * TERM setting doesn't matter, tried several options * editor doesn't seem to matter. have it in vi, nano, and even with `cat <<EOF` * ssh to a remote system from the cygwin tab does not fix the issue, same paste problems will persist. * can be reproduced with default windows terminal settings (well, you'll need to add a cygwin profile) * cygwin's zsh must be started from windows terminal. everything works fine when running from mintty. * running git for windows might also have this issue since it uses cygwin underneath. ### the following did not matter * copying/pasting in the same cygwin tab. when you paste, problem manifests. * copying in 1 cygwin tab, pasting in a second tab. when you paste, problem manifests. * copying from notepad. when you paste, problem manifests. * copy method: mouse select, ctrl+c, whatever. when you paste, problem manifests. * paste method: shift+insert, right mouse button or paste from the command palette. when you paste, problem manifests. * when copying with mouse, mouse position doesn't matter. you can either nicely start from the beginning of the line and stop at the last character several lines down, or just start & stop wherever you want. when you paste, problem manifests. ### why not just stop using zsh/cygwin 😄 ? * habbit, have been using it for 10+years * powershell is great, but i like zsh better for cli work. * wsl2 doesn't play nice with windows always on vpn for my setup * and a host of other semi technical/semi personal reasons ### and now for some files. 1. input text. copied from notepad via ctrl+c ``` GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it. For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions. ``` 2. pasted text in windows terminal. pasted in vi using shift+insert ![image](https://user-images.githubusercontent.com/39005454/127410462-968abb2c-b031-4c52-9d2b-a95d42e62086.png) 3. my settings.json (but also tried with a non modified - other as adding the cygwin profile - settings file in terminal 1.10.1933.0) [settings.json.txt](https://github.com/microsoft/terminal/files/6897015/settings.json.txt)

claunia commented

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

by using zsh from cygwin in windows terminal (or bash). just updated everthing cygwin related to be sure but have seen the issue for several months.

As a long-time Cygwin user myself I find it invaluable compared to WSL2 (although I do have it) and still use it as my main terminal. I don't use Terminal as I prefer mintty.

Any time I call out to a Windows programme (and so uses ConPTY) I get this same issue, it's a nightmare.

It's ConPTY at fault here as far as I can tell.

@ElvenSpellmaker commented on GitHub (Aug 10, 2021): > by using zsh from cygwin in windows terminal (or bash). just updated everthing cygwin related to be sure but have seen the issue for several months. As a long-time Cygwin user myself I find it invaluable compared to WSL2 (although I do have it) and still use it as my main terminal. I don't use Terminal as I prefer mintty. Any time I call out to a Windows programme (and so uses ConPTY) I get this same issue, it's a nightmare. It's ConPTY at fault here as far as I can tell.

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2022):

line breaks are introduced, but they shouldn't be

multiple lines get concatenated together when they should be separate

other / unrelated

#6987
- The illusive "something causes tmux panes to get overwritten into"
#9359
- mingw is outputting lines separated by \n instead of \r\n?
pasting anything over 500 characters into a cygwin tab in terminal is wack: https://github.com/microsoft/terminal/issues/6901#issuecomment-888696875
#11459
- Yea this isn't related
#11809
- Unrelated. UIA gets the wrong boundaries in conhost, for a wrapped line. That's weird, but not conpty related.
https://github.com/microsoft/terminal/issues/405#issuecomment-1327933466

@zadjii-msft commented on GitHub (Nov 8, 2022): ## line breaks are introduced, but they shouldn't be * #6901 (_this thread_) * #14035 * #11739 ## multiple lines get concatenated together when they should be separate * #8976 * #9933 * #15455 ## other / unrelated * #6987 * The illusive "something causes tmux panes to get overwritten into" * #9359 * mingw is outputting lines separated by `\n` instead of `\r\n`? * pasting anything over 500 characters into a cygwin tab in terminal is wack: https://github.com/microsoft/terminal/issues/6901#issuecomment-888696875 * #11459 * Yea this isn't related * #11809 * Unrelated. UIA gets the wrong boundaries in conhost, for a wrapped line. That's weird, but not conpty related. * https://github.com/microsoft/terminal/issues/405#issuecomment-1327933466 ## Related(?) PRs * #4415 * #15567 * #14936 * #14874

claunia commented

@mailinglists35 commented on GitHub (Nov 10, 2022):

probably worth mentioning the workaround of holding shift while selecting.

@mailinglists35 commented on GitHub (Nov 10, 2022): probably worth mentioning the workaround of [holding shift while selecting](https://github.com/microsoft/terminal/issues/14035#issuecomment-1251321075).

claunia commented

@gyorokpeter commented on GitHub (Nov 13, 2022):

I can reproduce, but in my case shift+select is not a workaround as it causes every newline to be removed, while what I'm copying is an ASCII rendered table that gets broken up by the incorrectly introduced newlines. I want to copy the table such that it preserves its table format.

I'm attaching a file demonstrating what the layout of the table looks like.
table.txt
Also I set my terminal settings to: 120 columns, (30 rows), font size 10. typeing the file will result in this:

And if I copy this output, the extra newlines are preserved. What I'm expecting is that only the newlines that were in the output are preserved, so the copied version matches that in the file.

For comparison in the legacy console app I can do this:

And if I copy this with Ctrl+A, the extra newlines are not copied.

@gyorokpeter commented on GitHub (Nov 13, 2022): I can reproduce, but in my case shift+select is not a workaround as it causes _every_ newline to be removed, while what I'm copying is an ASCII rendered table that gets broken up by the incorrectly introduced newlines. I want to copy the table such that it preserves its table format. I'm attaching a file demonstrating what the layout of the table looks like. [table.txt](https://github.com/microsoft/terminal/files/9997954/table.txt) Also I set my terminal settings to: 120 columns, (30 rows), font size 10. `type`ing the file will result in this: ![image](https://user-images.githubusercontent.com/1097079/201537999-e6d2f9df-ef2b-47ad-9450-a41d925672e2.png) And if I copy this output, the extra newlines are preserved. What I'm expecting is that only the newlines that were in the output are preserved, so the copied version matches that in the file. For comparison in the legacy console app I can do this: ![image](https://user-images.githubusercontent.com/1097079/201538145-dec0acfb-0cfe-4f37-9e30-8652f7cf68e2.png) And if I copy this with Ctrl+A, the extra newlines are not copied.

claunia commented

@fireattack commented on GitHub (Nov 25, 2022):

I didn't have this issue when using the actual Windows Terminal, however I have this issue when using the integrated terminal in VS Code: https://github.com/microsoft/vscode/issues/166247

The dev there said it is/was a WT bug since they use conpty, which is part of WT. They encouraged me to report it here, so I guess it's worth a mention.

@fireattack commented on GitHub (Nov 25, 2022): I didn't have this issue when using the actual Windows Terminal, however I have this issue when using the integrated terminal in VS Code: https://github.com/microsoft/vscode/issues/166247 The dev there said it is/was a WT bug since they use `conpty`, which is part of WT. They encouraged me to report it here, so I guess it's worth a mention.

claunia commented