Bug 53937 - RFE: Customizable colors of messages at bootup
Summary: RFE: Customizable colors of messages at bootup
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium enhancement
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-22 14:38 UTC by lukasas
Modified: 2019-08-22 10:58 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Semantic names for ANSI colors (39.51 KB, patch)
2014-01-05 02:17 UTC, Jacob Floyd
Details | Splinter Review
[WIP] Make colors configurable (9.16 KB, patch)
2014-01-07 15:39 UTC, Jacob Floyd
Details | Splinter Review
[WIP] Make colors configurable (9.16 KB, patch)
2014-01-07 15:57 UTC, Jacob Floyd
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description lukasas 2012-08-22 14:38:26 UTC
Hi, As many people I don't use "quiet" kernel parameter - I like to see what's going on in my system. I recently switched to systemd on Arch linux and as happy as I am with it, every time I see those green [  ok  ] I miss blue'ish messages from Arch's initscripts. This is not very important feature I know but would be great not only for Arch. If it's not huge problem it would be nice to give distributions free hand in color customization.
Comment 1 WorMzy Tykashi 2012-08-23 08:35:20 UTC
In addition to enabling distributions to "personalise" systemd's boot message colours, adding the ability for users to change these colours may be of particular use to people with impaired vision, i.e. colour blindness.
Comment 2 cfr 2012-09-25 22:40:50 UTC
Red/green colour blindness being the most common...
Comment 3 Igor 2012-10-24 10:53:47 UTC
It would be great if there was also possibility to change color based on regexp - for changing color of important messages.
Comment 4 Vlad 2012-10-24 14:53:41 UTC
@Igor: Though it would be nice, but for colorizing output a separate tools like ccze could be used as well. This subject is a bit too complex. I think ccze is the fastest one and written in C.
Comment 5 Jacob Floyd 2014-01-05 02:17:24 UTC
Created attachment 91505 [details] [review]
Semantic names for ANSI colors

This patch does not make the colors "configurable". It changes what the colors are called so that they are more semantic. That way, if you want to modify the ANSI codes in src/shared/util.h and recompile with your custom colors, you can know what the colors are used for.

I grepped through the code and looked at every instance where one of the colors was used to make sure the semantic meaning of each color was used consistently throughout.
Comment 6 Zbigniew Jedrzejewski-Szmek 2014-01-05 21:49:59 UTC
(In reply to comment #5)
> Created attachment 91505 [details] [review] [review]
> Semantic names for ANSI colors
This part looks OK. But without making colors configurable through a config file this doesn't really make sense. Can you make patch which makes it possible to use systemd.conf to assign colors to meanings?
Comment 7 Jacob Floyd 2014-01-07 15:39:09 UTC
Created attachment 91605 [details] [review]
[WIP] Make colors configurable

This patch adds color configuration options to system.conf and user.conf. It depends on the Semantic names patch.

I'm fairly confident in the parts that get/parse the configuration options, but I'm not sure about the variables/macros/functions that actually use the colors.

Using an extern variable will be a lot less efficient than inlining a string like we do now. Is this a good direction? What do you think of this so far?
Comment 8 Jacob Floyd 2014-01-07 15:57:14 UTC
Created attachment 91606 [details] [review]
[WIP] Make colors configurable

Same as the last patch, except I forgot to remove some arg vars I wasn't using. This removes them.
Comment 9 Zbigniew Jedrzejewski-Szmek 2014-01-11 20:35:52 UTC
> I'm fairly confident in the parts that get/parse the configuration options, Yes, that part looks good.

> I'm not sure about the variables/macros/functions that actually use the
> colors.
It's a start, but...

- There's no need to keep the "ansi"/"ANSI_" prefix in color variables and constants.

- I think it would be better to keep the ANSI_* constants, so you have e.g.
#define ANSI_RED_ON "\x1B[31m"
#define COLOR_BAD ANSI_RED_ON

- Would it be possible to call the colors by syslog priority
levels: ColorDebug, ColorWarning, ColorInfo, ColorNotice, ColorWarning, ColorError, ColorCritical, maybe with an additional ColorSuccess for green? This
would make it easier to relate to existing terms. You said that you went over places that colors are used, would it conflict significantly anywhere?

- Since those "constants" are now configurable, they must become arguments to the printf format strings almost everywhere:

-        fputs("\r\x1B[?25l" ANSI_HIGHLIGHT_GREEN_ON, stdout);
+        fprintf(stdout, "\r\x1B[?25l%s", color_good);

Efficiency is not "important". Output to the console is always excruciatingly slow, and the extra access to a variable is not an issue.

Also, at some point we would like to extend to 256 colors. I don't think there's anything in your patch which would be a problem, but please keep that in mind.
Comment 10 Lennart Poettering 2014-06-25 09:36:56 UTC
Humm, so I am really really not convinced this should go in.

What I'd be willing to add would be a patch that makes it possible to override at compile time the colors used, via variable definitions on the make command line, but runtime definitions (6 new options even!), or configure switches, no, please don't...
Comment 11 Zbigniew Jedrzejewski-Szmek 2019-08-22 10:58:29 UTC
Color of "OK" can be customized since https://github.com/systemd/systemd/commit/96164a3936.

For further enhancements, please open an issue or a pull request on the new bugtracker on https://github.com/systemd/systemd/issues/.


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.