It does not mean that we want ignore color blind people, obscure terminals or people who just don't like colors. The solution is to provide simple, elegant and package independent way how to control (disable) colorized output. And yes, aliases are not elegant.
The next util-linux release is going to introduce /etc/terminal-colors.d directory
to control colors for terminal utils. It's pretty simple:
Synopsis:
/etc/terminal-colors.d/[name.]disable /etc/terminal-colors.d/name.enableExamples:
- disable colors for all utils:
# touch /etc/terminal-colors.d/disable
- disable colors for dmesg(1):
# touch /etc/terminal-colors.d/dmesg.disable
- disable colors for all utils except dmesg(1):
# touch /etc/terminal-colors.d/disable # touch /etc/terminal-colors.d/dmesg.enable
The terminal-colors.d concept is completely open, it would be nice to see it supported in another projects (hint: gcc, grep, coreutils:-) too. It's so trivial that all you need is a few access(F_OK) calls. The thing we maintain in util-linux is terminal-colors.d.5 man page only.
Maybe later for util-linux we will also use the directory (or/and copy in $HOME) to store color schemes.
Keep your Bike-sheds colorized! :-)
UPDATE: since v2.25:
- $XDG_CONFIG_HOME/terminal-colors.d or $HOME/.config/terminal-colors.d overrides the global setting
- terminal-colors.d is possible to use for color schemes
echo 'alert 37;41' >> /etc/terminal-colors.d/dmesg.scheme
changes color used for kernel alerts in dmesg output - synopsis is /etc/terminal-colors.d/[[name][@term].][type], it means that for example /etc/terminal-colors.d/@vt100.disable disables colors for all vt100 terminals
- we have terminal-colors.d(5) man page with all details