Solved 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
A

a6h

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.
Click to expand...
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.
Click to expand...
 
I am all up for a colourful display.
Have aliases for ls -G and grep --color=auto . Both suppress the colour when piped.
 
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.
 
Good sometimes. When used correctly can easily identify information. When inconsistent can lead to wrong assumptions or just becomes pointless.
 
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:

forums.freebsd.org

Solved - Occasionally ugly results from script(1)

script(1) , for example. Much of it is a mess, and unrelated to my keystrokes. Is this type of mess maybe more likely to occur with fish(1)?
forums.freebsd.org forums.freebsd.org
 
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.
 
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.
 
Vull said:
I voted "good" but perhaps I misunderstand the question? Mean to say, implementing and using the NO_COLOR environment variable is good.
Click to expand...
The question (vote) is about using colours in terminal. Is it good or bad.
The NO_COLOR part is just extra info.
 
vigole said:
The question (vote) is about using colours in terminal. Is it good or bad.
The NO_COLOR part is just extra info.
Click to expand...
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.
 
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.
 
  • Thanks
Reactions: a6h
vigole said:
I like colour. e.g. IBM 5151.
Click to expand...
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 ;)
 
  • Thanks
Reactions: a6h
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.
 
mickey said:
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.
Click to expand...
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…
 
  • Thanks
Reactions: a6h
mickey said:
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.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top