Repository navigation
PowerShell's piping of strings with implicit trailing CRLF newlines causes problems with WSL on Windows #13579
Description
-
On Windows, PowerShell terminates strings sent via the pipeline to native programs with an implicit trailing CRLF.
-
If WSL (
wsl.exe) happens to be targeted, the ultimately invoked Unix utility usually only expects LF newlines, retaining the CR instances as part of the data, causing problems, as shown in theawkexample below.
Note:
-
I'm not sure where the proper place to resolve this is. Arguably, it is
wsl.exe(andbash.exe) that should translate CRLF sequences to LF sequences before processing stdin input, but that should only be done for text input, and it is only the calling shell that knows whether data is textual or not (if PowerShell is the calling shell, the input is always text, but that's not necessarily always true). -
A simple way to solve the problem is to make PowerShell always send stdin input with LF-only newlines (
"`n"), under the assumption that even native Windows programs recognize such newline sequences; while technically a breaking change, it may be a Bucket 3: Unlikely Grey Area change, and therefore acceptable.
Steps to reproduce
On Windows, with WSL and an Ubuntu distro as the default:
The following should output two one - a single line.
'one two' | wsl -e awk '{ print $2, $1 }' | should -be 'two one'Expected behavior
The test should pass.
Actual behavior
Expected 'two one', but got @('two', ' one').
What the output doesn't directly show is the root cause of the problem: two is actually two`r (verbatim two followed by a CR in the raw output, which awk retained as part of field $2 due to not considering CRs part of newlines), due to the input line using CRLF as the trailing newline.
Since PowerShell recognizes a CR by itself as a newline too, the output is parsed as two lines.
Environment data
PowerShell Core 7.1.0-preview.6
Activity
[-]PowerShell's piping of strings with CRLF newlines causes problems with WSL[/-][+]PowerShell's piping of strings with implicit trailing CRLF newlines causes problems with WSL on Windows[/+]microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.
Universal-Invariant commentedon Jan 31, 2026
This also seems to cause problems with inline code such as:
It seems that the end of lines in windows are causing invalid chars in the arguments passed to the commands. Putting all the commands on the same line works.