Open amarao opened 1 year ago
Cargo at this moment depends on termcolor
and atty
to detect color support. So far as I understand it, rules are:
atty
detects the stream source is a tty, hand over to termcolor
to determine.^1
TERM=dumb
or NO_COLOR
is set, disable the color support. ^2I am not an expert on tty specifications, but this seems to be more an enhancement of upstreams.
As of now, environment variable CARGO_TERM_COLOR=never
is at your service, as well as the configuration counterpart term.color
.
I'm curious, what is your reason for TERM=t10
?
Unknown terminal types should switch cargo into 'no colors' mode.
For some reason most new CLIs seem to be eschewing termcap and running heuristics on TERM
. Most I see just check TERM=dumb
though supports-color does do a few more checks.
At least when discussing it within the CLI-WG, someone made this statement
Remember that terminfo and termcap came from a time when there were a lot of very weird non-VT-series terminals around, and if you wanted your app to work at all, then you had to use the peculiar sequences required by those terminals. Nowadays it's reasonable to assume basic ANSI support. So, for colour if you just use plain 8-colour ANSI sequences and maybe bold, it shouldn't need any feature testing. So either aim for the lowest common denominator (easy) or try to get fancy and detect extra features (harder). Also bear in mind that the user might be running with either a white or black default background (colour 49). So blue on default-background might be readable on white, but probably won't be on black. This is all UNIX, though -- I don't know the Windows situation.
Problem
Some terminals lack ability to display colors. If
TERM
is set to the terminal type without color support, cargo should not put random (other terminal codes) on the screen.Steps
TERM=t10 cargo build
Expected result: no color codes. Actual result: color console codes in output.
Possible Solution(s)
Unknown terminal types should switch cargo into 'no colors' mode.
Notes
Version