No console colors on Windows 7 #55769
Comments
|
I can confirm this happens on Windows 8, and can confirm it is caused by rust-lang/cargo#5862. |
|
Will |
|
|
Currently Cargo will always capture the output of rustc meaning that rustc is never hooked up to a tty. To retain colors Cargo uses the `fwdansi` crate to ensure that ansi color codes are translated to windows terminal methods (and ansi codes otherwise just go their natural route on Unix). Cargo passes `--color always` to rustc to ensure that using a pipe doesn't trick it into not emitting colors at all. It turns out, however, that `--color always` ends up still accidentally using the native shell api on native windows shells. The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of `Always`, ensuring that when `--color always` is passed to rustc and its output isn't a terminal, we're always generating ansi colors regardless of the platform. Closes rust-lang#55769
|
Thanks for the report @jminer! I think this'll get fixed by #55788 @kennytm I think we only tested msys shells earlier, right? I think we're hitting this branch of |
|
@alexcrichton previously i did have tested on cmd.exe, but i haven't followed the recent changes which might have broken it |
|
Hm ok, that's worrisome! If #55788 doesn't do the trick I can try to investigate later, but it'll be quite awhile before I have a windows computer to test on again |
rustc: Request ansi colors if stderr isn't a tty Currently Cargo will always capture the output of rustc meaning that rustc is never hooked up to a tty. To retain colors Cargo uses the `fwdansi` crate to ensure that ansi color codes are translated to windows terminal methods (and ansi codes otherwise just go their natural route on Unix). Cargo passes `--color always` to rustc to ensure that using a pipe doesn't trick it into not emitting colors at all. It turns out, however, that `--color always` ends up still accidentally using the native shell api on native windows shells. The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of `Always`, ensuring that when `--color always` is passed to rustc and its output isn't a terminal, we're always generating ansi colors regardless of the platform. Closes rust-lang#55769
rustc: Request ansi colors if stderr isn't a tty Currently Cargo will always capture the output of rustc meaning that rustc is never hooked up to a tty. To retain colors Cargo uses the `fwdansi` crate to ensure that ansi color codes are translated to windows terminal methods (and ansi codes otherwise just go their natural route on Unix). Cargo passes `--color always` to rustc to ensure that using a pipe doesn't trick it into not emitting colors at all. It turns out, however, that `--color always` ends up still accidentally using the native shell api on native windows shells. The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of `Always`, ensuring that when `--color always` is passed to rustc and its output isn't a terminal, we're always generating ansi colors regardless of the platform. Closes rust-lang#55769
|
For posterity there was some discussion of why this isn't actually fixed on nightly right now, and @kennytm has a PR to |
|
Any chance this is getting fixed in the nearest future? |
|
@MSxDOS I pinged |
|
Nah we still need to go through the package release and update Cargo.lock processes 🙃 |
|
When this gets fixed, is there a possibility of adding some sort of UI test for this? This would be helpful for ensuring colors continue to work, when implementing #59346 |
|
|
|
@moxian it should work, but there is a bug in Cargo where colors are not working correctly, so that's why I have not updated things here, yet. I filed kennytm/fwdansi#1 but I have not heard back from @kennytm, yet. |
|
This should be fixed on the latest nightly (2020-07-31) via rust-lang/cargo#8540 and #74923. |
I just updated Rust at work, and now rustc has no colors in the console (Cargo still does). I'm using Windows 7 64-bit with Rust MSVC 32-bit. I tried 1.29 stable and it worked, but 1.30 stable and the latest nightly don't work. I have tried both cmd.exe and PowerShell and both look the same. This is a big regression in usability, so I'll probably downgrade back to a working version.
The text was updated successfully, but these errors were encountered: