Bug 90464 - RFE: systemctl: optionally turn off colors
Summary: RFE: systemctl: optionally turn off colors
Status: RESOLVED DUPLICATE of bug 64737
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-15 07:50 UTC by Jari Aalto
Modified: 2015-05-15 14:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Jari Aalto 2015-05-15 07:50:11 UTC
The standard output of systemctl(1) is in color. This is problem with accessing HOSTs from terminals and connections (like Phone sshd, etc.) that do not support color.

It would be preferable to display output in plain monochrome without ANSI color codes and have separate option --color to enable color in output. This would be similar to what e.g. GNU ls(1) does:

       Using color to distinguish file types is disabled both by  default  and
       with  --color=never.  With --color=auto, ls emits color codes only when
       standard output is connected to a terminal.  The LS_COLORS  environment
       variable can change the settings.

The program could also read environment variable  SYSTEMCTL_OPTIONS where users culd add the "--color" option as needed.

Ref: 
  "systemctl(1) please add option / make nocolor the deafult output"
  http://bugs.debian.org/785350
Comment 1 Lennart Poettering 2015-05-15 09:41:21 UTC
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.
Comment 2 Jari Aalto 2015-05-15 14:00:37 UTC
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,
Comment 3 Lennart Poettering 2015-05-15 14:09:45 UTC
(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.
Comment 4 Lennart Poettering 2015-05-15 14:14:09 UTC

*** This bug has been marked as a duplicate of bug 64737 ***
Comment 5 Jari Aalto 2015-05-15 14:18:09 UTC
Please rather add --no-color option
Comment 6 Jari Aalto 2015-05-15 14:20:53 UTC
I wouldn't want to muck with TERM settings; all funny things depend on it to have been set correctly.
Comment 7 Jari Aalto 2015-05-15 14:23:11 UTC
... 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.