Colore ta console

As for my previous article, I would like to talk about a not well known subject: How to color your console?

As administrator, and in particular when my eyes are tired, I am happy to read « OK » in green and « Not OK » in red. If you google with this subject, you will find many pages with simple tricks, but few with good explanations.

The purpose of this article is not to give hints about colorization, but to explain how it works and the main differences between a Linux terminal and a Windows console.

Linux terminal


A long time ago, a time that the youngest can not know, a computer terminal referred to an hardware device that was used for entering data into (a keyboard), and displaying data (a screen) from a computer. Somehow the end of a network.

VT100 was a video terminal. Its detailed attributes became the de facto standard for terminal emulators.
It communicated with its host system over serial lines using the ASCII character set and control sequences (a.k.a. escape sequences) standardized by ANSI. The VT100 was also the first Digital mass-market terminal to incorporate « graphic renditions » (blinking, bolding, reverse video, and underlining) as well as a selectable 80 or 132 column display.

Today we use mostly virtual terminals (in Linux, the first six virtual terminals provide a text terminal with a login prompt to a Unix shell) or emulators as xTerm that provides VT102 compatible terminals.

Here few escape sequences commonly used by VT100 compatible terminals.

How to colorize my VT100 terminal

The following lines should show « OK » in green and « Not OK » in red.

echo -e '\033[32m OK \033[0m'
echo -e '\033[31m Not OK \033[0m'

The previous script mingles Bash and VT102 escape sequences. Bash interprets and replaces « \033″ by the escape ASCII code. Then the VT102 emulators interpret « <ESC>[32m » as set the foreground color to green.


A good script should work not only on your computer but everywhere. So we should test the capabilities of our environment before relying on it. I found a lot of examples on Internet that perform tests based on $SHELL or $TERM environment variables. From my experience, these are not a good practices as I will explain.

Shell capabilities

$SHELL contains the login Shell, not the current Shell. Therefore scripts that use it are often buggy and people that use several Shells (like me) are very unhappy.

Simple is beautiful! I advice to do a non-portable script or to insert directly the escape character into your script in order to be independent of the Shell (its implementation of the escape characters and on its possible echo builtin command).

Good text editors show special characters, but it is painful to write « <ESC> » on a keyboard (on Windows you can press « ALT » and type « 0027 » on the keypad…)

echo '<ESC>[32m OK <ESC>[0m'
echo '<ESC>[31m Not OK <ESC>[0m'

Terminal capabilities

A script should check the terminal capabilities before to use VT102 color sequences. We can use the $TERM environment variable and the « test -t fd » conditionnal expression. But it is not easy.

$TERM can take a lot of different values (aterm, xterm, cygwin, etc.) Therefore it is difficult to create an exhaustive list of all terminals that understand the color sequences. Elsewhere, if you are bound to a pseudo-terminal it is not always possible to know the real capabilities of the real end-terminal. And I already experienced few bugs so…

Finally, I think the best practice is to implement a color parameter as the ls command:

  • never means the script will not generate VT102 color sequences
  • always means the script will generate VT102 color sequences
  • auto is where you try to implement a smart default behavior

function print_help() {
	cat <<EOF
# ...
              control  whether color is used to distinguish file types.  WHEN
              may be 'never', 'always', or 'auto'
# ...


if [ $color = always -o $color = auto -a -t 1 ]
	function print_KO() { echo '&#092;&#048;33[31mKO&#092;&#048;33[0m'; }
	function print_OK() { echo '&#092;&#048;33[32mOK&#092;&#048;33[0m'; }
	function print_KO() { echo 'KO'; }
	function print_OK() { echo 'OK'; }

Windows console

History (source Wikipedia)

MS-DOS 1.0 did not support the ANSI or any other escape sequences. Only a few control characters (CR, LF, BS) were interpreted.

MS-DOS 2.0 introduced the ability to add a device driver for the ANSI escape sequences – the de facto standard being ANSI.SYS. This continued to work through Windows 98. Extreme slowness and the fact that it was not installed by default made usage by software almost non-existent.

Console windows in Windows versions based on NT (Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008) do not support ANSI escape sequences at all. Softwares can manipulate the console with the ioctl-like system Console API.

Few examples

Many script languages (Perl, Tk, and so on) provide library based on the Console API to change the color of a Windows console. If you use them, the commands to change colors is interlaced with the text output.

Another solution is to use a library that provides an ANSI support. So POSIX guys can keep their habbits.

So how you would color your Windows console depends on the programming langage you chose and its helper libraries.


MS-DOS is a very poor language (not only for color). We can change the color of the entire Windows console, but we cannot change the color of a particular line.

REM MS-DOS example
REM Creates a Black background with light bright green text

My advice, do not use MS-DOS to colorize your output or do not use MS-DOS at all if you can.


I’m not completely a fan of PowerShell because of some strange syntaxes, supposed to make life simpler. But it is a very powerful language and, obviously, we can change color output easily.

Here is a powershell function that I use in my daily work. It is able to print a string with ANSI escape sequences to control colors. I use it basically when I run a remote command on a Linux machine.

### Author: Cyril Martin (mcoolive)

function Write-ColoredHost
		[String]$separator=" ",
		[System.ConsoleColor]$foregroundColor = $HOST.UI.RawUI.ForegroundColor,
		[System.ConsoleColor]$backgroundColor = $HOST.UI.RawUI.BackgroundColor
		$fgc, $bgc = $foregroundColor, $backgroundColor
		$token, $coloredTokens = ([Regex]"&#092;&#048;33[").split($_)
		Write-Host $token `
				   -noNewLine -separator $separator `
				   -foregroundColor $fgc `
				   -backgroundColor $bgc
		foreach ($coloredToken in $coloredTokens) {
			$colorCodes, $token = ([Regex]"m").split($coloredToken, 2)
				([Regex]";").split($colorCodes) | foreach-object {
					switch -regex ($_) {
						"^0{1,2}$" { $fgc, $bgc = $foregroundColor, $backgroundColor }
						"^30$"     { $fgc       = "Black"                            }
						"^31$"     { $fgc       = "Red"                              }
						"^32$"     { $fgc       = "Green"                            }
						"^33$"     { $fgc       = "Yellow"                           }
						"^34$"     { $fgc       = "Blue"                             }
						"^35$"     { $fgc       = "Magenta"                          }
						"^36$"     { $fgc       = "Cyan"                             }
						"^37$"     { $fgc       = "White"                            }
						"^39$"     { $fgc       = $foregroundColor                   }
						"^40$"     {       $bgc =                   "Black"          }
						"^41$"     {       $bgc =                   "Red"            }
						"^42$"     {       $bgc =                   "Green"          }
						"^43$"     {       $bgc =                   "Yellow"         }
						"^44$"     {       $bgc =                   "Blue"           }
						"^45$"     {       $bgc =                   "Magenta"        }
						"^46$"     {       $bgc =                   "Cyan"           }
						"^47$"     {       $bgc =                   "White"          }
						"^49$"     {       $bgc =                   $backgroundColor }
			Write-Host $token `
					   -noNewLine -separator $separator `
					   -foregroundColor $fgc `
					   -backgroundColor $bgc
		if (!$noNewLine) { Write-Host }

### A little test
$plink= # path of plink (see PuTTY)
$linuxServer= # hostname
$login= # username
&"$plink" -ssh $login@$linuxServer ls --color=always / | Write-ColoredHost

Java : quizz #4

Il y a quelques temps, une de mes connaissances (qui a délaissé le Java au profit du C embarqué) m’a montré quelques lignes de son code en Java et m’a demandé que va-t-il se passer à l’exécution ?

(Ci-dessous le code, que j’ai fortement allégé et gardé le nécessaire pour notre quizz :))

public class Quizz4 {

	public void handle(Object obj) {
		System.out.println("Handle object : "+obj);
	public void handle(String string) {
		System.out.println("Handle string : "+ string);

	public static void main(String[] args) {

		Quizz4 quizz4 = new Quizz4();
		Object obj = null;
		obj = new String ("my string");


Bien entendu, ici je simule certains traitements par un simple d’affichage à la console. Et donc, questions pour vous : à votre avis, si on exécute le code (la méthode main) :

A. le code ne se compile pas.
B. le code s’exécute correctement. Dans ce cas, que verrait on affiché à la console ? Et pourquoi ?
C. le code s’exécute correctement, mais on ne peut pas prédire son comportement. Et pourquoi ?

21 juin 11 – Soirée GigaSpaces au NoSQL User Group

GigaSpaces XAP ! Ce nom vous dit quelque chose ? Certainement car c’est ce que vous allez apprendre si vous êtes inscrit(e) à la session de formation publique GigaSpaces XAP.

Mais si vous n’êtes pas (encore) inscrit(e) à la formation et vous voulez savoir de quoi il s’agit ? Je vous invite alors à venir à la soirée GigaSpaces au NoSQL User Group qui sera assurée par Gauvain, le directeur de notre département Conseil et Solutions.

Ci-dessous les coordonnées de l’événement :

Lieu : OCTO Technology, 50 Avenue des champs Elysees, 75008 PARIS
Date : 21 juin 2011 – 19h
Pas d’inscription  nécessaire

Venez nombreux !