Bug 90464

Humm, no. I am pretty sure a terminal that does not support colors is the absolute exception these days. My phone ssh client certainly supports them.

I am also very sure that we should show colors by default. We use them conservatively, and they are very useful to direct attention to important fields or lines.

That said, I'd be willing to add support to turning of colors optionally, via some env var check, for example if TERM=dumb is set or so. But it really should be opt-out, not opt-in.

Your phone? Howabout others phones, models, what type or resolution of display....? Too many variables to generalize "it works for me".

Most of the program have colors off and provide separate option to turn it on. Usually if you want a feature to be active, then there is an option to enable it; in this case the --color option would be logical choice. 

Having to type exotic "TERM=dumb <command>" is contrary to every sensible way to deal with commands.

Please note that "colors" are sensitive to

  - Type of display (depends largely on monitor etc).
  - BG/FG on black/white, white/on black settings etc. Does 
    the colors burn into your eyes? black background probes to be hard on
    various colors.
  - Doesn't take into account visually impaired people

GNU programs are model citizens here so that they don't get on your way of working; you add more features with options as needed. That has proved to be a good design decisions that works for everybody,

(In reply to Jari Aalto from comment #2)
> Your phone? Howabout others phones, models, what type or resolution of
> display....? Too many variables to generalize "it works for me".

I am pretty sure that you have to look hard to find a terminal emulator these days that does not support color.

I am much more interested in providing good user experience for most people, and a way to configure things correctly for all others, than providing a bad experience for all.

> Most of the program have colors off and provide separate option to turn it
> on. Usually if you want a feature to be active, then there is an option to
> enable it; in this case the --color option would be logical choice. 

Well, I disagree. And given that this so far didn't come up precisely frequently I am pretty sure that this all is an exotic issue.

> Having to type exotic "TERM=dumb <command>" is contrary to every sensible
> way to deal with commands.

Well, TERM is the unix way to tell programs what your terminal can do and cannot do. you can set it in your .bashrc or similar, there's really no need to set it invidually for each invocation...

> 
> Please note that "colors" are sensitive to
> 
>   - Type of display (depends largely on monitor etc).
>   - BG/FG on black/white, white/on black settings etc. Does 
>     the colors burn into your eyes? black background probes to be hard on
>     various colors.
>   - Doesn't take into account visually impaired people

Oh god. With an opt-out switch systemctl is actually very much in line which behaviour of the popular desktops like GNOME or KDE: they use colors by default, and if you don't want this, you can enable high contrast themes and they are. 

Again, I am open to making this opt-out by checking $TERM. But the default really should be color-ful.

*** This bug has been marked as a duplicate of bug 64737 ***

Please rather add --no-color option

I wouldn't want to muck with TERM settings; all funny things depend on it to have been set correctly.

... just to put things in perspective, I'm taking about servers having systmd. Thay have no KDE, Gnome etc. We don't need any of "user experience" there.