rustc does not emit color output even with --color always with TERM=tmux-256color

[mqudsi]

rustc does not emit color output when running under a tmux session with TERM set correctly to tmux-256color (supported by the latest versions of ncurses) even with cargo +nightly build --color=always when TERM is set to tmux-256color. On the machine in question (macOS) the term file for tmux-256color is installed and infocmp returns the following:

#	Reconstructed via infocmp from file: /usr/local/Cellar/ncurses/6.0_4/share/terminfo/74/tmux-256color
tmux-256color|tmux with 256 colors,
	am, hs, km, mir, msgr, xenl,
	colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,
	acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
	bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
	clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=\r,
	csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
	cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
	cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
	cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
	dl=\E[%p1%dM, dl1=\E[M, dsl=\E]0;\007, ed=\E[J, el=\E[K,
	el1=\E[1K, enacs=\E(B\E)0, flash=\Eg, fsl=^G, home=\E[H,
	ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
	ind=\n, is2=\E)0, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,
	kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,
	kRIT=\E[1;2C, kbs=^H, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB,
	kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\E[4~, kf1=\EOP,
	kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P,
	kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~,
	kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~,
	kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~,
	kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R,
	kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~,
	kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~,
	kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~,
	kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R, kf4=\EOS,
	kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~,
	kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~,
	kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~,
	kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R,
	kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
	kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
	kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
	kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
	kf8=\E[19~, kf9=\E[20~, khome=\E[1~, kich1=\E[2~,
	kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
	kri=\E[1;2A, nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m,
	ri=\EM, ritm=\E[23m, rmacs=^O, rmcup=\E[?1049l, rmir=\E[4l,
	rmkx=\E[?1l\E>, rmso=\E[27m, rmul=\E[24m,
	rs2=\Ec\E[?1000l\E[?25h, sc=\E7,
	setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
	setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
	sgr=\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;m%?%p9%t\016%e\017%;,
	sgr0=\E[m\017, sitm=\E[3m, smacs=^N, smcup=\E[?1049h,
	smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m,
	tbc=\E[3g, tsl=\E]0;,

Per rust-lang/cargo#2877 cargo should be invoking rustc with the --color always flag, and indeed, cargo rustc --color always -- --color always returns 'Option color given more than once`.

Executing env TERM=xterm-256color cargo build also does not produce color output, but env TERM=xterm-256color cargo build --color always does.

[SimonSapin]

I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.)

If I add #[test] fn foo { TermInfo::from_env().unwrap() } in src/libterm/terminfo/mod.rs and run cargo +nightly test in src/libterm, I get panicked at 'called `Result::unwrap()` on an `Err` value: MalformedTerminfo("invalid magic number: expected 11a, found 21e")'. This appears to be while parsing /lib/terminfo/x/xterm-256color. This file is owned by the ncurses package on my system, which was recently updated to version 6.1 (possibly around the time that rustc stopped using colors). Their NEWS file does mention a new (incompatible) file format with a different magic number:

https://github.com/mirror/ncurses/blob/v6.1/NEWS#L93-L110

@alexcrichton Could rustc switch to whatever Cargo uses for colored terminal output?

[SimonSapin]

A work-around for my machine was temporarily downgrading the ncurses packages, and copying the old /usr/share/terminfo/x/xterm-256color file to ~/.terminfo/x/xterm-256color.

[alexcrichton]

Yes rustc should be able to switch at any time

[gchp]

Thanks @SimonSapin for the workaround!

[ExpHP]

Changing TERM from xterm-256color to xterm-color also seems to work as a temporary workaround. (note: this may affect other terminal applications)

[BurntSushi]

Another work-around if you're using sh:

alias cargo="TERM=xterm cargo"

This sets TERM to a possibly incorrect value, but limits its impact to only the output of a cargo command.

[adeschamps]

@SimonSapin That worked for me as well. I had no colour with ncurses-6.1-3. I downgraded to ncurses-6.0+20170902-3, which was what I had in /var/cache/pacman/pkg/, and now I have colour again.

[faulesocke]

I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with cargo build), colors from cargo itself are working fine. The default setting for $TERM there is: xterm-256color. The problem is fixed by setting $TERM to xterm-color.

Inside tmux however, colors work just fine, $TERM there seems to be screen by default.

[Eijebong]

Colors are fixed in the latest nightly (thanks to #48588 \o/)

[SimonSapin]

This is fixed for me in today’s nigthly, presumably by #48588.

[Robbepop]

With the current nightly I still have no colors with ncurses-6-1 and have to use ncurses-6-0-3 as a work around. What might still be broken?

[IsaacWoods]

Terminal colors are still broken with ncurses 6.1. cargo however, does use colors, so there's clearly still a discrepancy between how rustc and cargo use termcolor

[Flakebi]

@IsaacWoods It works fine for me with ncurses 6.1, even rustup has colors again since the last version 🎉.
I’d like to note though that things like RUSTC_WRAPPER=sccache destroy this for some reason (even if --color=always is set).
It took me some time to figure that out 🙂

[reillysiemens]

I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In #48588 @alexcrichton mentioned that

... the term crate remains in-tree for libtest. Changing libtest will be
a bit tricky due to how the build works, but we can always tackle that later.

What is the barrier to migrating libtest from term to termcolor?

For now, it's leaving my test output looking like this.

[euclio]

I have an in-progress patch for libtest but I ran into

error: cannot satisfy dependencies so `termcolor` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

I'm guessing that's the build issue that @alexcrichton is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.