Set TERM variable to xterm

[jhasse]

Hi!

Some programs (e. g. cmake's generated Makefiels) only output color, if the TERM env variable is set to a value like "xterm". I'm doing this manually atm, but it would be great if this plugin could set it automatically (if not already set).

[dblock]

Feel free to PR this. I think ansicolor should provide a term option that would default to none and could be set to xterm.

[jhasse]

I thought some more about this and came to the conclusion that there should be some standard environment variable to tell programs that it's okay to output ANSI colors. I've created this: http://bixense.com/clicolors

What do you think? Would you accept a PR which sets CLICOLOR by default?

[dblock]

I think it's not generic enough, unless it becomes some kind of adopted standard then I would vote no.

[jhasse]

I'm trying to push for it becoming a standard. So to get the ball rolling it would be great if this could already be set ;)

What do you mean by generic?

[ejelly]

The problem is that the TERM variable is telling the program or library (terminfo for example), how to put out things like colors. Do you just want to output a certain subset of ANSI escape sequences when CLICOLOR is set, or what is the plan? Granted, I don't think there's many terminals left nowadays which aren't close to vt100/xterm/ANSI somehow.

[jhasse]

Yes, certain subset. I guess I'll have to document that, but I haven't had the time to find out what escape sequences are supported exactly.

The problem with terminfo is, that it isn't supported on Windows (not even with MSYS AFAIK).

[ejelly]

In that case, I suggest embedding the name (once you found out a reasonable one) into the env variable's name, so that there's no confusion for the few remaining other, non-vt/ansi terminals.

The interaction with the TERM variable can be tricky though. As far as I understand, you want it to override a non-color TERM setting. But what if TERM specifies a better terminal, for example xterm-color256, wouldn't that be more desirable than the subset?

[jhasse]

What do you mean by "the name"? I think CLICOLOR(_FORCE) is already the best name as it is already used by OSX and some documentation about it exists on the web.

Indeed, it's desirable that if TERM specifies a better terminal, that should be used instead. But I guess the number of programs who use more than 16 colors is quite small. Most developers probably don't want to dig into terminfo just to print log messages in blue, warnings in yellow and errors in red ;)

[ssbarnea]

Some tools are not using colors or even throwing errors if the TERM variable is not set. I found quite a few over the years and I would find extremely useful for the plugin to define it if is not already defined (not to override). Probably xterm and and xterm-256color are both safe values to use.

[mkobit]

Is any environment variable set right now? This would definitely be useful.

[yurikhan]

The change in #109 sets the TERM variable to the color map selected in the job config, despite the here for setting that to xterm or xterm-256color.

Values for the color map include such strings as tango, vga and css. These values cause every well-behaving terminfo-using program to barf, because there is no terminfo definitions for these values of TERM.

Example: In my build script (which is also used by live people from an actual terminal emulator), I obtain the terminal-specific escape sequences for making text bold and reverting back to normal text, then use these to display messages (simplified here for expository purposes):

#!/bin/sh

set -e

SGR_BOLD=$(tput bold)
SGR0=$(tput sgr0)

echo Some ${SGR_BOLD}bold{$SGR0} text

When run from a correctly configured terminal emulator, this produces Some bold text. When run as part of a Jenkins build using the tango color map, I get:

19:52:05  tput: unknown terminal "tango"
19:52:05  tput: unknown terminal "tango"

Please do it right and set the TERM variable to a well-known, well-supported value (xterm or xterm-256color).