A Windows .exe repeatedly printing colored text in a WSL window eventually malfunctions

[mcclure]

Version

Microsoft Windows [Version 10.0.19045.2251]

WSL Version

• WSL 2
• WSL 1

Kernel Version

WSL1: 5.10.16; WSL2: 5.10.16.3-microsoft-standard-WSL2

Distro Version

WSL1: Ubuntu 20.04; WSL2: docker-desktop main-82475

Other Software

Rust 1.65.0 for Windows + ansi_term 0.12.1 (in test; possibly bug reproduces with any program)

Repro Steps

I develop Windows software but I trigger builds and execute software from WSL. While writing a Rust program [not my recommended test, but to test this run cargo.exe run -- data/sample.txt] using the "ansi_term" package, which supports both Unix and Windows . I found that when a Windows command-line program prints consecutive (touching) blocks of text with a color background, if this program is run inside of WSL, the background colors eventually start malfunctioning (not correctly printing the color in stretches of whitespace) and keep malfunctioning until the terminal is reset.

I have made a minimal repro program (source code src/main.rs). To test it, install a Windows version of Rust, checkout the repo and run cargo.exe run. It prints two columns of text with different shades of gray as background.

println!("{}{}{}{}", gray1.paint(string1), gray1.paint(" ".repeat(width1 - string1.len())),
    gray2.paint(string2), gray2.paint(" ".repeat(width2 - string2.len())));

The program repeats its input five times.

Expected Behavior

The program should display the same output regardless of whether I run it from a WSL prompt or a CMD.EXE prompt.

Actual Behavior

Running the program inside WSL, repetitions 1 and 2 print correctly. Repetition 3 is correct UNTIL the final line, which is supposed to be blank but background-colored on both sides. On the third repetition the background color is missing on the last line. On repetitions 4 and onward, most stretches of empty background text on the left (but not all; stretches of fewer than 8 characters still appear) do not have their intended background color. On repeat runs of the program, the problem is visible from the very beginning; this lasts until the terminal is reset (linux "reset" command or Windows Terminal "Clear Buffer" action).

Running the program in a CMD.COM or Powershell window the colors look correct no matter how many times the program runs.

Strangely, if inside WSL I > the output of rust-bug.exe to a file (in the repo one such file is saved as TEST.txt and then run cat TEST.txt all text displays correctly.

Testing with different output strings produces unpredictable results, but the constant is that eventually the uncolored-background bug starts appearing.

Notes
Is this bug in WSL or in Rust/ansi-term? I do not have convenient means to test this bug with a program not written in Rust. I was going to file the bug on ansi-term first but on noticing that the ansi-term output works in CMD.EXE concluded that means the problem is in WSL. If ansi-term is doing something incorrect I would be happy to refile on them.
The output contains many square brackets; could this be relevant? Changing the [ and ] in the output to M and N did not change the bug expression.
Does cargo.exe make a difference? Running the program directly rather than cargo.exe makes no difference regardless of where it is run. When running it directly on WSL rather than running through Cargo, I find repetition 2 does not express the bug on the final line. This isn't significant and the difference would probably disappear with different output strings.
Does the terminal program matter? I usually run Windows Terminal 1.15.2874.0, however, I got the same results if I opened a normal CMD.EXE window and executed wsl.exe from there.
What about "ansi_term::enable_ansi_support()"? The documentation for ansi-term explains that "on Windows 10" an enable_ansi_support() support function must be run at the start of the program. If I omit this line, I find that CMD.COM and Powershell print no Ansi printable characters (unless run in cargo.exe, which I assume enables ansi support for its build-progress animation). However, on WSL the presence or absence of this line makes no difference, either to the program functioning or the bug.
Is it important that the program generates separate strings for the text and the empty background spaces? If I concatenate the two strings before passing them to gray.paint() with format!, the bug happens the same.
Do the colors chosen for gray1 or gray2 matter? No, I can change them and the bug still happens.

Diagnostic Logs

n/a

[microsoft-github-policy-service]

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!

[SnoopJ]

Your description of the problem not presenting with CMD.exe makes me wonder if this Windows Terminal issue is possibly related. I have not stumbled on this in the same manner you have (in my case a subprocess was involved), but the information there about the very fiddly nature of the Windows Terminal may possible be useful to you since Microsoft's bot has automatically abandoned your report because Microsoft did not engage with it.