Terminal output contains line breaks / new lines when copying

[fireattack]

Type: Bug

Steps to Reproduce:

1. Create a python script with the content below

print("this is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentensethis is a very long sentense~end~")

2. In terminal (I use CMD, but can also be reproduced in PowerShell), run the script
3. Copy the output from VS code terminal and paste it into an empty editor tab.

Expected: the output should have no line break or new lines.

Observed: it randomly added some line breaks / new lines. It does not happen if I use stand alone cmd window, or Windows Terminal.

I never see this happen with my other machines before. But I can reproduce this consistently with this laptop. It happens with all the outputs. I tested with stable (my profile) and insider portable (brand new profile), same issue.

VS Code version: Code - Insiders 1.74.0-insider (ef41557, 2022-11-11T05:19:14.666Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: Yes

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 x 2904)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: unavailable_off vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	11.87GB (3.90GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions: none

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
vsc_aacf:30263846
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805:30301674
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30404738
cppdebug:30492333
vsclangdf:30492506
c4g48928:30535728
dsvsc012cf:30540253
pylantcb52:30590116
pyindex848cf:30577859
nodejswelcome1:30587009
gswce1:30602633
34cci188:30599831
pyind779:30600159
dbltrim-noruby:30604474

[meganrogge]

This issue seems to originate from an upstream component and is not something VSCode can fix by making a change to our code. As such, I will go ahead and close it. Please try to reproduce in Windows Terminal and report to microsoft/terminal with repro steps.

If you cannot reproduce in Windows Terminal, chances are it's fixed in a later version of Windows. You can read more about how we consume conpty here. Thanks for understanding.

/label upstream terminal-conpty windows

[fireattack]

Wait what? Why does it have anything to do with Windows Terminal? I tested with cmd.exe/powershell, not WT.

"Terminal" in title means integral terminal in VS Code, not WT.

And WT itself (while irrelevant) does not even have this issue.

@meganrogge : can you please clarify what you mean? Otherwise, I have no way to report it to https://github.com/microsoft/terminal since I have no issue there.

[meganrogge]

Apologies for the confusion. Here's the relevant part of my message

If you cannot reproduce in Windows Terminal, chances are it's fixed in a later version of Windows. You can read more about how we consume conpty here. Thanks for understanding.

[std-move]

@meganrogge Any chance this could get fixed in Win10 19044/19045? The regular editions are supported at least till 2025-10-14, with IoT Enterprise LTSC (for which volume licencing is newly available) supported until 2032-01-13.

It seems like a bug that should be fixed as part of a cumulative update.

[Tyriar]

This is indeed fixed in Windows with microsoft/terminal#6901 when conpty started allowing the terminal to handle line wrapping. To get this change you need a later version of Windows. We hope to eventually ship conpty with Windows but we're blocked on the terminal shipping their nuget package for that.

FYI it's inconsistent because before we had to guess which lines wrapped which we did based on the last char in the line.

[lgarron]

This is indeed fixed in Windows with microsoft/terminal#6901 when conpty started allowing the terminal to handle line wrapping. To get this change you need a later version of Windows. We hope to eventually ship conpty with Windows but we're blocked on the terminal shipping their nuget package for that.

For those of us who still see this issue on macOS, is there another issue we can follow?

[Tyriar]

@lgarron this shouldn't happen on macOS, if it does then chances are it's happening because the application you're running in the terminal moved the cursor to the next time instead of properly wrapping text.