I've tried to print something in color on the terminal, but I found it rather hard to do so
In this Screenshot you can see my attempts to recreate a working shell script solution in rust and I failed badly.
As you can see the in the output, I have dealt the wrong way with the Escape Characters in rust. Do you have a solution for this?
Thank you for reading thus far
Greetings, Nils Martel
\\ means "print \ without doing anything special with it", which is exactly opposite of what you want for an escape code. You'd need \x1B or such instead.
I have tried it myself and it is great, the ease of use is astounding!
I need a wee bit more control in this case, but your answer is more than welcome, thank you!
I know the docs say it works in Windows: but it does not. I tried it on an app I have that builds on both Windows and Linux: on Windows it just output [e33 or similar before each line; on Linux it produced colored output as expected. That's why I've gone back to termcolor.
Looking at the code, it definitely has no Windows specific support. Windows has a number of different cases:
For terminals like MinTTY (e.g., what Cygwin comes with IIRC), ANSI escape codes on Windows will "just work" exactly like they do on macOS or Linux.
For other terminals in Windows (like cmd.exe or PowerShell), ANSI escape codes never "just work." Coloring via the Windows console APIs will, however, always work.
As of Windows 10, you can put Windows console based terminals into a virtual terminal processing mode. Once this is enabled, ANSI escape sequences will "just work" like they do everywhere else.
The colored crate neither uses the Windows console APIs, nor does it put the console into VT processing mode. Therefore, it cannot work on Windows. This is further evidenced by this bug report. So in this case, I'd say the README is wrong.
ansi_term supports all of the above except for coloring via the console APIs. Therefore, it works in most situations you might want. termcolor goes a step further and provides support for coloring using the console based APIs, which means you get colors on Windows 7, which isn't possible with ansi_term. The cost is termcolor's crude API. Namely, doing coloring with the console APIs requires synchronous communication while you're printing to the screen, where as ANSI escapes are just in-band with the output itself. With the latter, it's trivial to put ANSI escape sequences inside strings and manipulate them, and then just send them to the output device like anything else. There's a lot of flexibility there. With console coloring, you need to go out of your way to do special things when you print stuff. (Either with an explicit cross platform API, or via an ANSI escape code interpreter, or similar.)
Folks seem to really like having a highly convenient API for coloring, and as long as you're OK with dropping Windows 7 support, then that's a good way to go. But not everyone is OK with dropping Windows 7 just yet, and thus, you have a splintered ecosystem.