Reputation: 139
my $PSVersion output is as follows:
Name Value
---- -----
PSVersion 7.0.1
PSEdition Core
GitCommitId 7.0.1
OS Microsoft Windows 10.0.19041
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
If I run
wsl -l
my output appears in the console as:
Windows Subsystem for Linux Distributions:
Ubuntu-20.04 (Default)
ubuntu-20.04-systemd
If I run
wsl -l | Out-File foo.txt
it appears in the file as:
W i n d o w s S u b s y s t e m f o r L i n u x D i s t r i b u t i o n s :
U b u n t u - 2 0 . 0 4 ( D e f a u l t )
u b u n t u - 2 0 . 0 4 - s y s t e m d
I've tried specifying different output encodings to Out-File to no avail. I'd like to understand what's going on and how to get around it.
Thank you!
Upvotes: 1
Views: 484
Reputation: 439682
wsl -l
unexpectedly uses the UTF-16LE ("Unicode") character encoding for its output, resulting in extra NUL
bytes (0x0
) getting inserted between ASCII-range characters (which can appear like spaces) when PowerShell interprets the output (which it invariably does if you capture or redirect the output; display in the console is not affected), based on the encoding stored in [Console]::OutputEncoding
, which defaults to the system's active OEM code page.
The solution is to (temporarily) set [Console]::OutputEncoding
to match wsl
's output encoding:
$orig = [Console]::OutputEncoding
[Console]::OutputEncoding = [System.Text.Encoding]::Unicode # UTF-16LE
wsl -l > foo.txt # > is effectively like Out-File
[Console]::OutputEncoding = $orig
See this answer for custom function Debug-String
, which facilitates diagnosing such encoding problems.
Upvotes: 3