Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wsl.exe --help option garbles output when piped to more #4456

Closed
henrik-jensen opened this issue Aug 30, 2019 · 6 comments
Closed

wsl.exe --help option garbles output when piped to more #4456

henrik-jensen opened this issue Aug 30, 2019 · 6 comments
Labels
needs-investigation likely actionable and/or needs more investigation

Comments

@henrik-jensen
Copy link

henrik-jensen commented Aug 30, 2019

  • Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.18362.295]

  • What you're doing and what's happening:

Start cmd.exe prompt

c:\> wsl --help | more

Result - every char is postfixed with newline it seams:

wsl_--help_vs_more

  • What's wrong / what should be happening instead:

Readable (more) paged output expected.

PS!
This is not a console issue. It's the wsl.exe --help option only, outputting extra (newline?) chars.
e.g. c:\> wsl ls --help | more works fine.
PS!!
Tested with both c:\> chcp 850 (default on my system) and c:\> chcp 65001, unicode output. Same result.

@henrik-jensen henrik-jensen changed the title wsl.exe --help option garbels output when piped to more wsl.exe --help option garbles output when piped to more Aug 30, 2019
@henrik-jensen
Copy link
Author

Brute workaround (working on my system win 10 1903 danish ):

c:\>wsl --help | wsl tr -d '\000\015' | more

but of course that seems quite fragile though.

The format that 'wsl --help' spits out seems to be some bastard kind of utf16LE but where every '\r\n' becomes '\r\r\n'.
So the above effectively creates a UTF8 with unix line ends output, but will only work on ascii text.

@therealkenc
Copy link
Collaborator

therealkenc commented Aug 31, 2019

Interesting report. Yep there is an extra \r in there alright. For the giggles I created a UTF16LE file with VS Code (I never touch the stuff personally) and System32\more.com does eat it correctly. So wsl.exe's output does appear to be malformed.

Alternative work-around below. I set my Windows system locale to Chinese with the new fangled Windows Terminal v0.4.2382.0 preview.

C:>wsl --help | wsl iconv -c -f utf16 -t utf8 | more

Seems to take believe it or not:

image

No word on whether that text makes any sense (I believe it may not) but it does match the non-more output.

@henrik-jensen
Copy link
Author

henrik-jensen commented Aug 31, 2019

@therealkenc - Excellent, using the right tool for the job. Much better and robust workaround, also works in the standard (old) console (The one used when calling cmd.exe, what's its name? ).

@therealkenc
Copy link
Collaborator

Windows Console (vs newspeak Windows Terminal). Yes those words are synonyms but they had to call it something.

I found with wide characters like Chinese the (scare quote) "old" Windows Console mangled some glyphs. I just tried Windows Terminal on a lark. Western-ish charsets will possibly be fine in both. Can't speak to Danish, lolz.

@NotTheDr01ds
Copy link

Really the same root cause as #4607, for which a workaround is available starting with release 0.64.0. I've confirmed that setting $env:WSL_UTF8=1 (or the equivalent in other shells) causes wsl --help | more to display correctly.

For those who aren't able to upgrade to Windows 11 at this time, the workaround in this comment by falloutphil should also work.

Copy link
Contributor

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-investigation likely actionable and/or needs more investigation
Projects
None yet
Development

No branches or pull requests

3 participants