Bug 53937

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.

Red/green colour blindness being the most common...

It would be great if there was also possibility to change color based on regexp - for changing color of important messages.

@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.

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.

(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?

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?

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.

> 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.

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...

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/.