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

CMD does not show Unix LF when pasting #942

New Issue
Open
opened 2026-01-30 22:12:03 +00:00 by claunia · 7 comments
claunia commented 2026-01-30 22:12:03 +00:00
Owner
Copy Link

Originally created by @Biswa96 on GitHub (May 10, 2019).

Originally assigned to: @zadjii-msft on GitHub.

  • Build 18890 (18894 on the way...)
  • What doing: Create a file with Unix (LF) line endings. For example,
echo foo
echo bar

Paste it in CMD window. The output is fooecho bar. The output should be in separate lines. Try the same in mintty. It shows correct output.

Originally created by @Biswa96 on GitHub (May 10, 2019). Originally assigned to: @zadjii-msft on GitHub. * Build 18890 (18894 on the way...) * What doing: Create a file with **Unix (LF) line endings**. For example, ```cmd echo foo echo bar ``` Paste it in CMD window. The output is `fooecho bar`. The output should be in separate lines. Try the same in mintty. It shows correct output.
claunia added the Product-ConhostIssue-BugArea-InteractionPriority-2 labels 2026-01-30 22:12:03 +00:00
claunia commented 2026-01-30 22:12:04 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 10, 2019):

I think this is a notoriously long-standing bug with cmd.exe. @paulcam206 might have more to share on this topic. I'm fairly sure this falls under the category of "we can't change cmd.exe anymore".

I just read the "paste" bit - I'm probably wrong about that above.

@zadjii-msft commented on GitHub (May 10, 2019): ~I think this is a notoriously long-standing bug with cmd.exe. @paulcam206 might have more to share on this topic. I'm fairly sure this falls under the category of "we can't change cmd.exe anymore".~ I just read the "paste" bit - I'm probably wrong about that above.
claunia commented 2026-01-30 22:12:04 +00:00
Author
Owner
Copy Link

@FrankHB commented on GitHub (May 10, 2019):

I agree this should better be fixed, but it can also be a feature :)

I'm working on a REPL which accepts one line per input by default. The language is free-form, which can have multiple lines in the script files. I save some pieces of test code in the script files, and each test case can have more than one lines of code. The LF ending makes more than one lines can be selected together and copied. When they are pasted into the console, the REPL ignores the LF characters, so these lines are automatically concatenated into one. If the bug is fixed, such trick/abuse will be broken.

@FrankHB commented on GitHub (May 10, 2019): I agree this should better be fixed, but it can also be a feature :) I'm working on a REPL which accepts one line per input by default. The language is free-form, which can have multiple lines in the script files. I save some pieces of test code in the script files, and each test case can have more than one lines of code. The LF ending makes more than one lines can be selected together and copied. When they are pasted into the console, the REPL ignores the LF characters, so these lines are automatically concatenated into one. If the bug is fixed, such trick/abuse will be broken.
claunia commented 2026-01-30 22:12:04 +00:00
Author
Owner
Copy Link

@Biswa96 commented on GitHub (Jul 17, 2019):

Any 'official' reply?

@Biswa96 commented on GitHub (Jul 17, 2019): Any 'official' reply?
claunia commented 2026-01-30 22:12:04 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 17, 2019):

I don't know what's at the root of this problem, if it's a recent regression or not, or if it's truly a bug or just "weird things that conhost does that we can't fix cause legacy reasons". I'm throwing it on the 20H1 milestone to make sure someone investigates, though it might be a while. If someone else is passionate about fixing this and would like to dig into why this is happening, power to you :)

@zadjii-msft commented on GitHub (Jul 17, 2019): I don't know what's at the root of this problem, if it's a recent regression or not, or if it's truly a bug or just "weird things that conhost does that we can't fix cause legacy reasons". I'm throwing it on the 20H1 milestone to make sure someone investigates, though it might be a while. If someone else is passionate about fixing this and would like to dig into _why_ this is happening, power to you :)
claunia commented 2026-01-30 22:12:04 +00:00
Author
Owner
Copy Link

@Biswa96 commented on GitHub (Jul 17, 2019):

fixing this and would like to dig into why this is happening

cmd.exe is not open source.

@Biswa96 commented on GitHub (Jul 17, 2019): > fixing this and would like to dig into why this is happening cmd.exe is not open source.
claunia commented 2026-01-30 22:12:05 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 17, 2019):

Yea but conhost is, and conhost is going to be far more valuable in debugging this than cmd.exe.

@zadjii-msft commented on GitHub (Jul 17, 2019): Yea but conhost is, and conhost is going to be _far_ more valuable in debugging this than cmd.exe.
claunia commented 2026-01-30 22:12:05 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 30, 2019):

At first I thought: "this is something that we can't fix because it's legacy cmd madness". But now I'm not so sure.

Lets look at what happens when you try to paste

echo foo
echo bar
echo baz

with only LF line endings:
image

This makes it seem like COOKED_READ in conhost is not properly breaking up the lines on a LF-only paste. In fact, the problem might be even higher, in our reading from the clipboard itself. Let's look at this code, which is responsible for taking the clipboard data and generating INPUT_RECORDs from it:
083be43700/src/interactivity/win32/Clipboard.cpp (L140-L183)

The most interesting bit is on line 171:

     if (IsInVirtualTerminalInputMode() && currentChar == UNICODE_LINEFEED) 
     {
           currentChar = UNICODE_CARRIAGERETURN; 
     }

When we're in VT input mode (read:wsl), we'll turn single LF characters into a CR before handling the paste. This was in order to solve microsoft/WSL#2006.

If I take out the IsInVirtualTerminalInputMode check, this will fix the cmd scenario:
image

Now the real question is: Is this a safe change? What will this possibly regress? Let's discuss! @miniksa @DHowett-MSFT @carlos-zamora

Also for linking internally: MSFT:20169262 deals with this for batch files, which is almost certainly unsolvable.

@zadjii-msft commented on GitHub (Sep 30, 2019): At first I thought: "this is something that we can't fix because it's legacy cmd madness". But now I'm not so sure. Lets look at what happens when you try to paste ```cmd echo foo echo bar echo baz ``` with only LF line endings: ![image](https://user-images.githubusercontent.com/18356694/65890203-1d593400-e368-11e9-9cbe-340eb883d160.png) This makes it seem like `COOKED_READ` in conhost is not properly breaking up the lines on a LF-only paste. In fact, the problem might be even higher, in our reading from the clipboard itself. Let's look at this code, which is responsible for taking the clipboard data and generating `INPUT_RECORD`s from it: https://github.com/microsoft/terminal/blob/083be43700c01604983a9ff67e9fe6edab8ad0e5/src/interactivity/win32/Clipboard.cpp#L140-L183 The most interesting bit is on line 171: ``` c++ if (IsInVirtualTerminalInputMode() && currentChar == UNICODE_LINEFEED) { currentChar = UNICODE_CARRIAGERETURN; } ``` When we're in VT _input_ mode (read:wsl), we'll turn single LF characters into a CR before handling the paste. This was in order to solve microsoft/WSL#2006. If I take out the `IsInVirtualTerminalInputMode` check, this will fix the cmd scenario: ![image](https://user-images.githubusercontent.com/18356694/65891140-aa50bd00-e369-11e9-99b7-0a708a22b1be.png) Now the real question is: Is this a safe change? What will this possibly regress? Let's discuss! @miniksa @DHowett-MSFT @carlos-zamora <hr> Also for linking internally: MSFT:20169262 deals with this for batch files, which is almost certainly unsolvable.
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 Area-Interaction Issue-Bug Priority-2 Product-Conhost
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#942
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?