NO_COLOR: output with ANSI colour by default, good or bad?

Output with ANSI colour by default. Good or bad?

  • Bad

    Votes: 6 42.9%
  • Good

    Votes: 7 50.0%
  • I'm using VT220

    Votes: 1 7.1%

  • Total voters
    14

vigole

Daemon

Reaction score: 1,455
Messages: 1,268

What is NO_COLOR?
NO_COLOR is a hint to the software running in the terminal to suppress addition of color.

More about NO_COLOR at:
no-color.org

Background:
quote #1 from no-color.org
An increasing number of command-line software programs output text with ANSI color escape codes by default. While some developers and users obviously prefer seeing these colors, many users don’t. Unfortunately, every new piece of software seems to have a different way of disabling colored text output and some software has no way at all.
quote #2 from no-color.org
Command-line software which adds ANSI color to its output by default should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color.
 

Geezer

Aspiring Daemon

Reaction score: 374
Messages: 662

I am all up for a colourful display.
Have aliases for ls -G and grep --color=auto . Both suppress the colour when piped.
 

tingo

Son of Beastie

Reaction score: 638
Messages: 2,543

It is neither good or bad. But sometimes, it makes my workflow harder. Example: many (most?) color schemes used by todays CLI (command line interface) software assumes a specific color scheme (like light text on a black background), but the color scheme I use is different (light grey background with black text). This results in hard to read colorized output, forcing me to take extra steps (like piping output to get rid of the colors) in my workflow.
 

mrbeastie0x19

Member

Reaction score: 49
Messages: 84

Good sometimes. When used correctly can easily identify information. When inconsistent can lead to wrong assumptions or just becomes pointless.
 

grahamperrin

Daemon

Reaction score: 675
Messages: 2,143

My answer will probably be Good, because I nearly always benefit from colours, …



… my experience is slightly tainted by the experience below, but (sorry) I can't tell whether there's any overlap with this topic:

 

Vull

Aspiring Daemon

Reaction score: 443
Messages: 734

I voted "good" but perhaps I misunderstand the question? Mean to say, implementing and using the NO_COLOR environment variable is good.

On the other hand, is "output with ANSI color by default" good? No, I think such default behavior is "bad" which is why I like having a NO_COLOR option to suppress it. ANSI color by default is what I think of as the Linux way, and not as the FreeBSD way.

I'd rather have "no color" be the default, with an option to turn it on if I want it. In practice, however, it amounts to basically the same thing, since either way you look at it, it gives each user the power of choice.
 

Geezer

Aspiring Daemon

Reaction score: 374
Messages: 662

The best option would be to have colour - if you want it - and have the ability to turn it off with NO_COLOR.

The discussion could be: Is NO_COLOR set or not as default. (A bit like the sh/csh and ee/vi arguments.)



Oh yes, and I think the environment variable would work a lot better if it was NO_COLOUR.
 
OP
vigole

vigole

Daemon

Reaction score: 1,455
Messages: 1,268

I voted "good" but perhaps I misunderstand the question? Mean to say, implementing and using the NO_COLOR environment variable is good.
The question (vote) is about using colours in terminal. Is it good or bad.
The NO_COLOR part is just extra info.
 

Vull

Aspiring Daemon

Reaction score: 443
Messages: 734

The question (vote) is about using colours in terminal. Is it good or bad.
The NO_COLOR part is just extra info.
Okay. Since I can't qualify my answer I'll withdraw my vote. In order of preference I'd rather have:
  1. Colorized output, but only as long as the NO_COLOR environment variable is honored,
  2. No color at all,
  3. Colorized output with no way of turning it off.
 

Zirias

Son of Beastie

Reaction score: 1,517
Messages: 2,637

So you don't like games/lolcat? 😏

But seriously, I voted "good". Of course some things must be considered when colorizing output by default:
  • The colors must actually be "helpful", therefore, emphasize structure to make it easier to grasp. Don't use colors just because you think "I love the rainbow".
  • Only colorize by default if you're indeed outputting to a terminal (and use e.g. curs_termcap(3) instead of literal ANSI sequences to avoid unnecessary breakage with exotic terminals)! Pipes and redirects should never be affected.
  • There must be a way for the user to disable it (e.g. because of a broken terminal, or because you're just a grumpy color-hater 😈).
That all said, some global standard to disable colors could make sense, but I don't see a pressing need.
 
OP
vigole

vigole

Daemon

Reaction score: 1,455
Messages: 1,268

There must be a way for the user to disable it (e.g. because of a broken terminal, or because you're just a grumpy color-hater 😈).
I like colour. e.g. IBM 5151.
 

Zirias

Son of Beastie

Reaction score: 1,517
Messages: 2,637

I like colour. e.g. IBM 5151.
Uhhhhh .... green was pretty hyped back then, this went as far as the Commodore 1081 color CRT, meant for C64/C128/Amiga, came with a "green switch" 😳 (although some said green was for the poor, amber was so much better 🤪)

Ok, sorry, that's off-topic ;)
 

astyle

Daemon

Reaction score: 467
Messages: 1,078

Ahh... another American vs British vs Aussie dialect debate, even though English is the common language. ;)
 

mickey

Aspiring Daemon

Reaction score: 310
Messages: 754

Having or not having colored output should be controlled by the presence/absence of the corresponding features in the termcap/terminfo entry of the terminal type you are using, not by means of yet another environment variable, which only adds to confusion. If you dislike colors, use a termcap/terminfo entry that does not declare color features and you wont be bothered by them again, lyke ever.
 

Zirias

Son of Beastie

Reaction score: 1,517
Messages: 2,637

Having or not having colored output should be controlled by the presence/absence of the corresponding features in the termcap/terminfo entry of the terminal type you are using, not by means of yet another environment variable, which only adds to confusion. If you dislike colors, use a termcap/terminfo entry that does not declare color features and you wont be bothered by them again, lyke ever.
If you look at the link in the OP, they do have a valid argument against that approach. But then, I think being able to disable colors somehow should be enough, given the "guidelines" I outlined above are met…
 

Vull

Aspiring Daemon

Reaction score: 443
Messages: 734

Having or not having colored output should be controlled by the presence/absence of the corresponding features in the termcap/terminfo entry of the terminal type you are using, not by means of yet another environment variable, which only adds to confusion. If you dislike colors, use a termcap/terminfo entry that does not declare color features and you wont be bothered by them again, lyke ever.
Good point but the way the question was phrased seems to assume that programmers are hard-coding ANSI escape sequences rather than relying on termcap/terminfo. This is especially true in Linux-land, and more and more code from Linux-land has been making its way into FreeBSD-world through the ports collection. This is a trend that seems to be accellerating, whether we like it or not.

It's definitely true that, if people would just use tput or other software that relies on terminal capabilities databases (termcap/terminfo), instead of hard-coding their escape sequences, there wouldn't be so much of a problem with this. But TERM=xterm-256color is so ubiquitous nowadays, that I think many userland programmers just assume everyone has it, and wants to use it, or they just don't care or don't know how their escape sequences affect everybody else.

Complicating matters further is the fact that BSDs tend to lean more on termcap, whereas Linuxes tend to lean more on terminfo. Programmers porting from one platform to another have to deal with that, and I think a lot of them probably just find it a whole lot easier to hard code their xterm escape sequences.
 
Top