Il y a maintenant un peu plus d’un an, Teo Mrnjavac, membre de la communauté KDE et un des auteurs d’Amarok, avait écrit un article intéressant sur des utilitaires en couleur pour le terminal.

Cet article va dans le même sens car pour moi, un shell personnalisé est tout de suite plus attrayant et l’utilisation de couleurs, lorsqu’elles le sont à bon escient, y contribue. L’autre aspect important et l’interactivité que permet un shell bien configuré, par le biais de la complétion des commandes par exemple. À ce titre, je ne saurais plus me passer de zsh (voir cet ancien article notamment).

Le shell

Un shell bien personnalisé, ça commence par un PS1 (invite de commande) agréable. Chez moi, il ressemble à ça:

C’est donc un classique utilisateur@hôte avec le chemin du dossier courant. Ce dernier se trouve d’ailleurs raccourci si nécessaire:

Il change également de couleur en fonction des permissions du dossier courant:

Un autre point sympa: si je passe en root, cela se remarque tout de suite:

A noter également que la couleur du nom de l’ĥôte change en fonction de l’hôte. Ainsi, ça permet de savoir encore plus facilement sur quelle machine on se trouve (et éviter d’éteindre par mégarde un serveur plutôt que son poste de travail par exemple…). Merci à Alex à qui j’ai piqué la configuration de base il y a quelques années.

Mon shell intègre également un autre prompt, situé à l’extrême droite, lorsque le dossier courant est un dépôt git ou mercurial (je n’utilise pas svn, bazaar ou autre donc n’en tiens pas compte). Il permet de visualiser en un coup d’oeil l’état du dépôt: la branche courante, le nombre de nouveaux fichiers, si des changements ont été apportés, s’ils ont été commités, s’il y a besoin de compléter un merge, etc.

Pour plus d’information à ce sujet, je vous laisse vous référez à cet article que j’ai publié il y a plus d’un an en arrière.

Cela rend tout de suite le terminal plus agréable un prompt du genre, pas vrai? Oui mais, il y a moyen de faire encore mieux. Je ne vais pas parler ici de toutes les astuces que l’on peut utiliser via le ~/.zshrc car cela serait d’une part trop long et que ce n’est pas le sujet de cet article. En revanche, puisque cet article traite de couleur et de shell, voici une astuce que je trouve fort sympa. Peut-être que vous connaissez le shell fish (friendly interactive shell)? C’est un shell qui possède beaucoup de fonctionnalités très intéressantes (complétion, suggestions basées sur l’historique, utilisation intensive de couleurs, etc.), la plupart activée par défaut. Exemple de complétion dans un dépôt git:

On peut remarquer sur cette dernière image une chose intéressante: les commandes valides sont en bleu alors que les commandes non-valides sont en rouge. On voit également que les chaînes sont colorées en jaune. Plutôt sympa non? Personnellement, j’adore! Comme je n’utilise pas le shell fish mais zsh, j’utilise un plugin dénommé zsh-syntax-highlighting qui se charge d’effectuer le même rendu au niveau des couleurs pour zsh. Exemple de rendu (les exécutables valides étant ici en vert):

À propos de commandes valides ou non, j’ai également une autre personnalisation de mon prompt que je trouve intéressante: l’indication du code de sortie d’une commande lorsqu’elle retourne sur une erreur. Exemple:

Avec tout ça, on se retrouve déjà avec quelque chose d’intéressant. Cependant, à côté du shell à proprement parler, il y a également les utilitaires en ligne de commande que l’on utilise qui peuvent être paramétrés ou même remplacés par des équivalents plus colorés. Je vais donc tâcher d’en faire ici une liste non exhaustive.

ccze

CCZE permet de colorer des fichiers de logs. J’utilise cette fonction dans mon ~/.zshrc afin quand je dois débloquer une situation en consultant des logs.

1
2
3

logtail () {
            tail -f $1 | ccze -A
}

Ce qui donne quelque chose du genre:

Merci à Frank qui m’avait fourni l’astuce.

ack

ack est une alternative à grep(1), écrit en Perl, qui se trouve être particulièrement pratique pour trouver ce que l’on cherche parmi des fichiers source par exemple:

git et mercurial

Il ne s’agit pas ici d’alternative mais simplement de configurer ces gestionnaires de version afin que le retour de leur commandes respectives soit un peu plus coloré. Pour git, j’ai ceci dans mon ~/.gitconfig:

1
2
3
4
5
6

[color]
        branch = auto
        diff = auto
        interactive = auto
        status = auto
        ui = auto

Et ceci dans mon ~/.hgrc pour mercurial:

1
2
3
4
5
6
7
8
9

[extensions]
color                   =

[color]
status.modified = blue bold
status.added    = green
status.removed  = red
status.unknown  = black bold
status.deleted  = red bold

C’est aussi tout de suite plus agréable:

Si vous n’utilisez ni git ni mercurial et que votre gestionnaire de version ne supporte pas les couleurs (svn par exemple), vous pouvez toujours vous rabattre sur colordiff afin d’avoir au moins un diff(1) en couleur.

htop

On tombe cette fois dans un grand classique. htop est un bon remplaçant à top(1) (même si la qualité de son code source laisse un peu à désirer…):

cdu

Vous connaissez certainement du(1), cet utilitaire qui donne une estimation de l’utilisation de l’espace disque occupé par le dossier donné en argument? cdu en est une alternative en couleur:

C’est pratique pour un coup d’oeil rapide bien que je trouve ncdu, une version ncurse (sans couleurs) de du(1), plus pratique à cet égard.

dfc

C’est presque un peu inutile que je le présente sur ce blog mais dfc fait selon moi une excellente alternative à df(1) (qui se charge de plus que simplement ajouter de la couleur d’ailleurs):

Si l’outil ne vous plait pas, il existe des alternatives telles que pydf ou cdf.

freec

Frank, que j’ai déjà cité dans cet article, a écrit un programme alternatif à free(1): freec.

Autres

Je trouve la liste déjà relativement exhaustive mais il en existe encore d’autres.

• ls++: La plupart des gens activent les couleurs pour la commande ls(1) via LS_COLORS. Personnellement, cela me suffit mais ceux qui en veulent plus peuvent passer par ce wrapper Perl.
• colorgcc: Qui se révèle être un bon palliatif à gcc pour les utilisateurs habitués à compiler avec clang.
• colormake: Pour colorer make(1).
• vimpager ou encore une configuration de most ou less pour les pages de manuel.
• …

Je suis sûr que vous saurez la compléter par des utilitaires que vous appréciez aussi. ;)