Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Take Command tab not displaying coloured text from Rust compiler

Jul
177
1
For the obvious reasons I had cause to upgrade my development system from Windows 8.1 to 10 (22H2) today and I am now suffering from an odd problem that was not happening with the same version of Take Command (v25) under 8.1 in that some of the colouration of the text output by the Rust compiler is being lost (or perhaps more accurately, greyed out) in a Take Command tab. The output looks perfectly fine in a TCC console window but as you can see from the two screenshots (TCMD first, then TCC) not all of the colour transfers through:

take_command_rust_output_uncoloured_20230116.PNG


tcc_console_rust_output_coloured_20230116.PNG


Is there some obvious setting I'm missing that controls this (albeit that nothing about the TC set up has changed, only the OS)?

Also. I realise that my version of Take Command is fairly long in the tooth but I downloaded an evaluation copy of v29 and that displays the same behaviour.

Cheers, Steve
 
If you do a color bri cya on bla in a Take Command tab, do you get the correct bright cyan, or the dingy gray?

If you detach the offending tab, does the console window still show the incorrect colors?
 
Last edited:
Detaching the tab results in a TCC window with the correct colours. Conversely, attaching the console window that I'd previously created whilst testing this results in a tab without the colours in exactly the same way (ie. the earlier output from rustc is dithered grey but the final word warning: is in bright yellow and the word Finished in bright green). It might be worth noting that in both cases the text before the compiler output is coloured as expected, with input commands in bright yellow and an error during TCSTART execution in bright red, which is per my option settings.

The color command gets me the output in whatever loud colours I choose, including bright cyan and bright yellow even when scrolled off.
 
This may be no help at all.

Do you know if the output from RUST goes to stdout, stderr, or a combination of the two? You might be able to find out by prefixing your RUST command with 2>nul (get rid of stderr) and 1>nul (get rid of stdout). I don't know if it's significant, but I noticed this oddity (below). It doesn't show a difference between a console and TCMD. Top to bottom, are TCC in TCMD, TCC in a console, TCC in Windows Terminal. I have ErrorColors=Bright Red on Black and ^e[32m is green.

1673980077028.png


I can't explain the difference between the console and TCMD and I can't reproduce it because I don't have RUST or anything which produces such a variety of colors.

The Windows 10 console is quite different from older ones. Are you using the new console (the default, I believe) or the legacy one? You can find out in the console's properties dialog (Options tab).

1673980985305.png
 
And moments later, having made no changes and in new instances of TCC and TCMD, I cannot reproduce that anomaly.

1673982268225.png
 
The Windows 10 console is quite different from older ones. Are you using the new console (the default, I believe) or the legacy one? You can find out in the console's properties dialog (Options tab).

View attachment 3830
Good shout Vince. Setting that option resolves the issue, which I guess is good enough for me because I have no intention of switching away from Take Command (at least not until I give up on Windows for my development box entirely and switch to a Linux variant, which probably won't happen now until Windows 10 - 'the last Windows ever' - goes EOL in a couple of years or so) which makes those new features irrelevant here.

FWIW I've been running with the new style console on my gaming rig for years without noticing any issues, so it is just the immensely colourful Rust compiler output that is at the root of all this.
 
It's not clear ... legacy mode fixed it or legacy mode was the problem?
 
Sorry, enabling legacy mode resolved it and I have no problem with that as 'the final solution' although Rex may eventually care to fix the underlying issue.
 

Similar threads

Back
Top