[Fwd: Bootscripts style guide (long)]

James Robertson jwrober at linuxfromscratch.org
Fri Sep 24 11:01:05 PDT 2004


I have cross posted this to lfs-dev, blfs-dev and lfs-hackers.  All 
comments should go to lfs-dev.  Thanks


I was working with Nathan Coulson last night on IRC.  We were testing
out ideas for using color in the bootscripts package.  Currently (as of
20040923 version) we support six color codes:

	1: NORMAL - This is regular console gray.  You see this a lot

	2: SUCCESS - This is green.  You see this represented as
	   [  OK  ] now, where the OK part is green.

	3: WARNING - This is yellow.  Just like SUCCESS, the WARN part
	   of [ WARN ] is yellow.

	4: FAILURE - This is red.  Just like WARNING, the FAIL part of
	   [ FAIL ] is red.

	5: INFO - This is cyan.  It is not used yet (hence this email)

	6: BRACKET - This is blue.  You see this in the ['s.

With the work of DJ, Nathan and myself, we have updated the boot_mesg()
extensively.  It supports a lot of options now (Nathan if I missed,
please correct me):

	1: You can pass "\n" in a string to the function call and it
	   will force a line break.  E.G. boot_mesg "Hello\nWorld"
	   will come out as


	   on the screen.  The more \n's you put in the string, the
	   more newlines you get.  The function also counts those
	   \n's with a grep so that we can support moving back up
	   as many lines as we want or need to to place a status at
	   the right.

	2: You can pass a "-n" to prevent echo (used in the function)
	   from sending a newline at the end.  The old way was to just
	   use echo -n "string".  We can use the new function's power
	   and still keep this simple functionality.

	3: You can pass color as part of the string.  E.G.

		boot_mesg "Hello World" $INFO

	   will spit out Hello World in cyan to the console

	4: You can use it to build (concatenate) a string message.  Each 	
subsequent call to the function before a call to
	   print_status() will build them together.  E.G.

		boot_mesg "Hello World" $INFO
		boot_mesg " I am cool" $NORMAL

	   will spit out "Hello World I am cool" and the "Hello World"
	   part will be in cyan and the "I am cool" part will be console
	   gray.  The print_status() function will nuke the variable we
	   use ($BOOTMSG) in the boot_msg() to allow you to start over.

	5: Any calls to the function will also be sent to the syslogd
	   user.log process (once it is running).  All color codes are
	   dropped for this.

	6: Long strings are split with a sed line to force a wrap based 	
	   on the size of a console you have.  This is mostly for those
	   folks that use framebuffer consoles.  The old bootscripts
	   wrote error messages designed for the lowest common
	   denominator (80x25).  We can now accomodate any screen size
	   and have messages look better to boot!

Now with this tidbit of info out. I want to get to the meat of the
email.  I would like know what you all want to see in the various colors
(essentially, how much color do we want to see on the screen).  I am
going to put down a proposal and let you all vote or make suggestions.
I will be out of town for the weekend, so I won't be able to respond
till Sunday or Monday.

	1: Use NORMAL the most, as we do today.  NORMAL is like it
	   sounds.  Basic, non-descript messages about something go out
	   as normal.  Normal is also the default when the function is

	2: If a process generates a WARN or FAIL, the whole message
	   should be in the same color instead of just the [ WARN ] or
	   [ FAIL ] part like it is today.  This help to have these
	   things stand out on the screen.  For those scripts that
	   generate a one line message that is built from doing multiple
	   things (think mountkernfs, or modules), then the part that
	   failed or generated a warning would be in that color, but not
	   the whole string.  For example, when loading modules, we
	   start with a "Loading modules: " string.  We then add to the
	   string as we go along and place some more text in the string
	   for each module as it is loaded.  Say you are loading three
	   modules: parport_pc, tulip and a sound driver.  If parport_pc
	   fails, then that part of the string would be red.

	3: INFO would be used to display something that is one step up
	   in importance than NORMAL, but not as high as WARNING or
	   FAILURE.  For example, we could put "Loading modules: " into
	   INFO color to show you that more is to come.  The same would
	   be true for "Mounting kernel based filesystems: ".  Another
	   use for INFO is in checkfs, where we may get a result back
	   from fsck that is not really the level of WARNING or FAILURE,
	   but needs to be highlighted.  A third use of INFO is also in
	   checkfs.  If we see the file /forcefsck, then we do
	   something.  INFO would be use to show the string "/forcefsck
	   found, running fsck..." again because this is out of the
	   norm, but not a warning for a failure message.

The function does have some bugs (a second message is forthcoming) that
we need to work out before everything is ready to go.  Please let us
know what you want.

FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User   -- #6981   -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer    -- http://{blfs-}bugs.linuxfromscratch.org

More information about the lfs-dev mailing list