-   Slackware (
-   -   color font on startup (

cisneros 07-28-2013 10:12 PM

color font on startup
so, i just installed salix in a vm to test it out, and i looked that it has these colors on the messages on the boot, is there a way to do this on slackware? or it just not possible? thanks a lot.

Richard Cranium 07-28-2013 10:22 PM

Yes, it's possible. The default scripts just don't do it, but there's support for it in /etc/rc.d/init.d/functions.

cisneros 07-29-2013 12:53 AM

so its something that needs to change in every single script?

not really sure what the functions file do, but in these lines

MOVE_TO_COL="echo -en \\033[${RES_COL}G"
SETCOLOR_SUCCESS="echo -en \\033[1;32m"
SETCOLOR_FAILURE="echo -en \\033[1;31m"
SETCOLOR_WARNING="echo -en \\033[1;33m"
SETCOLOR_NORMAL="echo -en \\033[0;39m"
seems like the colors for the text are already there, so... im lost, gonna dive into it later. seeya.

Richard Cranium 07-30-2013 12:28 AM

Well, I partially lied up there.

/etc/rc.d/rc.cups uses the stuff in functions to give you the green OK and red FAIL colors.

Woodsman 07-30-2013 12:15 PM

You can blame me. :) I used to have colorized rc.d scripts at my web site before I ended the site.

Several years ago the Zenwalk developers adopted my colorized scripts and modified the color scheme to their liking. Salix is maintained by folks who originally helped maintain Zenwalk. Some of them left the Zenwalk project to start Salix. The Salix folks continued the colorized scripts with their distro.

That said, as Salix is advertised as compatible with the parent Slackware, you should be able to use all of the Salix scripts in Slackware or at least most of them. If you are uncertain about all changes, use a graphical diff front-end, such as kompare, to review the differences between the Salix and Slackware scripts.

Be forewarned that some of the doinstall scripts in Slackware packages automatically overwrite existing rc.d scripts. The rc.udev script is an example. Some sort of backup strategy is needed to preserve colorization efforts. I maintain a *.bak file that is easily restored.

Remember that rc.d scripts provided in third party packages, such as from, do not contain colorization. I have to edit those scripts and maintain backups too.

The colorized [ok] and [fail] outputs used in the rc.cups script is mostly a Red Hat convention. Most distros derived from Red Hat use the same convention.

As colorization is not supported upstream, there is some maintenace involved to keep the scripts colorized while not changing the function of the scripts. Every time I update to a new Slackware release I spend about an hour reviewing all scripts and adding colorization to new scripts.

In all, not a lot of work to have colorized scripts. I still use all of my colorized scripts. Helps with readability when the boot and shutdown process scrolls. Without a splash image during the boot and shutdown events, the colorized output does provide a more "professional" look too. At least for desktop systems. Like the honey badger, server folks probably don't give a sh-t. ;)

cisneros 07-30-2013 12:33 PM

so, it is something that needs to be adjusted in every single script?, do you have any guide or tips to start with it? thanks a lot. Im gonna check salix scripts, wanna see diffs between the files.

Woodsman 07-30-2013 12:46 PM

Remember there is no upstream support for colorization. Therefore nothing exists. :) Every script that is colorized must be edited. That initial effort takes a while to complete, but the Salix scripts already have most of that done.

The /etc/shell-colors file contains the escape sequences for the color scheme used. The modified rc.d scripts use the echo -e command. For example, from rc.M:

echo -e "${BOLDYELLOW}Going to multi user mode.${COLOR_RESET}"

Each modified rc.d script (or any other colorized script, such as user scripts stored in /usr/local/(s)bin), need to source /etc/shell-colors at the top of the script.

Inserting the escape sequences in /etc/shell-colors allows for easier readability in the rc.d scripts as to which color is being used because human usable color names are used.

Richard Cranium 07-31-2013 09:34 PM

Is /etc/shell-colors a Salix thing?

Woodsman 07-31-2013 09:51 PM


Is /etc/shell-colors a Salix thing?
That was my invention, although originally I had a different file name. :) The Zenwalk folks changed the name to shell-colors and I liked that name too. Perhaps the Salix devs who once worked on Zenwalk changed the name.

Kallaste 07-31-2013 10:47 PM

That's pretty neat, actually. I might give it a go as well. Nice work, Woodsman!

cisneros 07-31-2013 10:50 PM

it would be great that slackware 14.1 have colorization on the boot. just sayin.

Woodsman 07-31-2013 11:29 PM


it would be great that slackware 14.1 have colorization on the boot. just sayin.
Would be great, yes, but now convince Pat. :)

Anybody could propose a collection of colorized scripts, but the shell-colors file has to support a simple way to disable all colorization. I don't know how the Salix folks handle this as I have not looked at their file, but on my system I use a script variable of COLORED_SCRIPTS=yes and a simple if/then test in the script. When disabled all colors are set to ${ESC}00m. Like this:


# /etc/shell-colors
# This file provides escape code options for adding color to echo and
# printf script commands. Source this file as necessary. Add additional
# colors if desired.

# Sourcing this script allows writing scripts with human readable
# color references rather than embedding the actual raw escape codes,
# which few people remember or know. A human readable variable enables
# a person to read a script and know the intended color.

# Write a script to include the human readable color code variables.
# Example:
# echo -e "${BOLDRED}This is a warning message!${COLOR_RESET}"
# echo -e "${BOLDWHITE}Your network interface is: ${BOLDGREEN}eth0${COLOR_RESET}"

# When this script is sourced and run, the $COLORED_SCRIPT variable will
# determine whether the end-user sees color. For example, people running a
# server might care less about colored scripts, but people running desktop
# boxes likely will want otherwise.

# Modify this variable to produce the desired effect:


# This color scheme looks good with a black background.
# Feel free to modify for other background color schemes.
if [ "$COLORED_SCRIPTS" = "yes" ]; then
  # user wants colorized scripts :-)
  # user does not want colorized scripts :-(

With this setup, all rc.d scripts have the colorization code in them. If $COLORED_SCRIPTS = no, then the effect is to print no color.

I have no idea whether adding color to scripts slows the boot process. I'm guessing that even if you convinced Pat to add colorization, the default likely would be off. :)

I use a black terminal backgrounds. The color scheme I use won't work with white backgrounds. So the shell-colors file would have to have alternate color schemes for different backgrounds. As the basic console is black I don't know how I'd handle different color backgrounds. Possibly some testing would reveal a single color scheme that would work with most background colors.

I don't have any related notes in my shell-colors, but in my modified rc.d scripts I use a basic color strategy for consistent stdout. I use red for failure messages, yellow for warnings and runlevel changes, blue for the beginning announcement of each script, green to emphasize data in a message, and white for emphasizing certain stdout messages or to separate stdout messages into sections. For example:

echo -e "${BOLDWHITE}Starting loopback interface ${BOLDGREEN}lo${BOLDWHITE}:${COLOR_RESET}"

Possibly another option in shell-colors would be to add a list of color types. That is, something like BOLDFAILURE, BOLDWARNING, BOLDINTRODUCTION, BOLDMESSAGE, BOLDDATA. Then the rc.d scripts could use that instead of BOLDRED, BOLDYELLOW, BOLDBLUE, BOLDWHITE, and BOLDGREEN.

In summary, alternate color schemes are needed for different background colors and there would need to be a consensus opinion of the overall color strategy as well and neither can conflict with the other. Things can get complicated because of different user desires. If you get that far then you might be able to bend Pat's ear, but if not you could submit the scripts as a collection. :)

solarfields 08-01-2013 03:40 AM


before I ended the site
why, man, why...

you had so many cool things there!

All times are GMT -5. The time now is 04:42 AM.