"hidden" null and empty lines in the output of wsl.exe

[pigeonlips]

Windows Version

Microsoft Windows [Version 10.0.22621.1702]

WSL Version

1.2.5.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

any

Distro Version

any

Other Software

none

Repro Steps

a couple of things first :

• I took a look through open issues and couldn't find anything similar, however it might have been reported differently. Happy for this to be closed if its a known thing or tracked else where.

• Also I've worked between linux and windows for way too many years and so I wanted to say that WSL has been fantastic ! A real game changer ! My full thanks to everyone that's contributed to the project !

Onto the issue then. The output from the wsl.exe seems a bit odd. Running commands like -l -d etc all look fine from the terminal and 100% work as expected, however if you try and do anything with the output, I've run into a couple of issues. For example,

>_ # if you pipe the output to foreach, you'll get extra lines. 

>_ wsl -l |  % { $_ }

>_ # If you send the output to a file you will get "null" between each character. 

>_ wsl -l | ? {$_ -ne ''} | out-file -Encoding ascii $env:temp\wsl.txt

>_ code $env:temp\wsl.txt

Maybe some some of encoding issue ? I stumbled across this while I was trying to wrap the output of wsl -l in FZF and pass it back to wsl -d.

>_ wsl -d "$(wsl -l -q | ? {$_ -ne ''} | fzf)"
  
  Argument --distribution is missing a required parameter.

I use WezTerm as my terminal emulator bur I have tried all the above on a few others including Windows Terminal ( Version: 1.17.11461.0) Alacritty etc and they all seem to act the same.

Anyway its not a big deal to me. Just thought I'd raise it.

Again, Fantastic Project ! Much Love !

Expected Behavior

I assumed the output of wsl would be returned as a clean string.

Actual Behavior

output returns nulls between characters and extra lines possible encoding issue?

Diagnostic Logs

No response

[pigeonlips]

My apologies. I clearly didn't look hard enough. It looks like this was a known thing and highlighted better here. I case anyone else ends up here, there's a environment variable that can be used to return clean output :

$env:WSL_UTF8=1

Works on 0.64.0 and higher. I'm curious as to why its not returning the cleaner UTF8 are there any plans for that in the future ?

[OneBlue]

Indeed WSL_UTF8 is the right way to solve this.

Unfortunately, we can't make it the default because of backwards compatibility.