Notez que la version stable actuelle (0.50.1) ne gère pas l’iPhone, il vous faudra prendre la bêta (0.50.2b8) qui elle, marche a merveille. La version actuelle 0.50.6 fonctionne à merveille.

Il existe une alternative gratuite et open source nommée iTunesFS, disponible ici.

1. Le prompt bash et la manipulation des titres des fenêtres
2. Navigation dans les répertoires en ligne de commande et les alias
3. L’historique et le complètement avancé avec bash
4. Les entrée/sorties, leur redirection et les motifs du shell

Ce billets est quant à lui consacré à l’enchaînement de commandes, au contrôles des tâches (jobs) puis à deux petites astuces bien pratiques à utilisées sans modération. Je pense que ce billet est le dernier de cette série, les prochains autour du shell seront probablement sur les scripts et diverses astuces plus ou moins pointues comme les deux présentées à la fin de ce billet.

Enchaîner les commandes

L’utilisation probablement la plus courante d’un shell consiste à taper une commande, regarder sa sortie ou son résultat et éventuellement recommencer en fonction du résultat précédent. On peut aussi vouloir exécuter plusieurs commandes à la suite. Pour cela, on peut écrire un script ou une fonction bash (ce sera probablement l’objet d’une prochaine série de billets) mais il est aussi possible de le faire en mode interactif.

Plusieurs commandes à la suite sans condition

Pour éxécuter plusieurs commandes de suite, il est possible de les écrire les unes à la suite des autres en les séparant par un point-virgule, par exemple :

Cette liste de 4 commandes est regroupée sur une ligne, j’aurais aussi bien pu taper chacune d’elle sur une ligne séparée, le résultat aurait été le même. Si l’une d’entre elles échoue, les autres sont quand même exécutées.

Plusieurs commandes à la suite sous condition

Chaque commande lancée renvoie normalement un code de retour. Par convention, un résultat normal (sans erreur) renvoie un code de retour égale à zéro, si quelque chose se passe mal, ce code est différent de zéro et peu avoir différentes significations selon les programmes. La variable $? contient le code de retour de la précédente commande lancée. En séparant des commandes par &&, bash vérifie que la commande a bien renvoyé un code de retour nulle avant d’éxécuter la suivante, sinon il interrompt la suite, exemple :

Cette suite de commande est interrompue après le test -L car son code de retour n’est pas nulle puisque /tmp n’est pas un lien symbolique.

Contrôle des tâches

En ajoutant le caractère & à une commande, celle-ci est lancée en arrière plan tout en restant « attaché » au shell qui l’a lancé. On peut aussi faire passer en arrière plan une commande avec le raccourci Ctrl+z. Pour récupèrer la main sur le programme passé en arrière plan, il est possible d’utiliser la commande fg . J’utilise couramment ce mécanisme lorsque j’édite un fichier à l’aide de vim en ssh et que je me rend compte que je dois lancer une autre commande, je peux alors faire Ctrl+z pour récupèrer le shell, je lance ma commande puis je tape fg pour reprendre la main sur mon éditeur. fg accepte en paramètre un entier qui indique le numéro de la tâche à remettre en avant plan. Ce numéro correspond à l’ordre dans lequel les programmes ont été mis en arrière plan.
Quelques trucs…

Un peu de couleurs avec grep

Les émulateurs de terminal sont capables d’afficher quelques couleurs (en général 16). La configuration par défaut sous la plupart des distributions fait en sorte que ls affiche sa sortie avec des couleurs en fonction du type de fichier ou de son extension. D’autres programmes sont capables d’améliorer leur affichage avec un peu de couleur.

C’est par exemple le cas de grep qui permet de filtrer un texte selon une expression rationnelle en mettant en avant les morceaux de texte correspondant au motif, c’est assez pratique lorsque l’on tente de déchiffrer un fichier de log ou tout autre fichier texte.

Cette ligne permet d’obtenir tous les alias de 2 caractères. Ce qui donne dans mon terminal :

Pour que ce comportement soit systématique, il suffit d’ajouter les lignes suivante dans son fichier ~/.bashrc :

Pour que tout appel à grep (et à egrep) mette en valeur le motif trouvé.

Suivre un fichier de log

tail est un programme qui propose d’afficher les n dernières lignes ou les n derniers octets d’un fichier. Il dispose d’une option -f (pour follow) très intéressante permettant de suivre un fichier pour faire défiler les dernières lignes ajoutées. Cette option combinée à d’autres utilitaires de traitement de texte (cut , sed , grep , …) permet de suivre différents types de journaux facilement, deux exemples courants :

À noter dans ces exemples, l’ajout du paramètre –line-buffered pour indiquer à grep de traiter les données ligne par ligne plutôt que par un buffer plus grand. Cette option permet de ne pas avoir de latence entre le moment ou tail écrit une nouvelle ligne et le moment ou grep la traite.

1. Le prompt bash et la manipulation des titres des fenêtres
2. Navigation dans les répertoires en ligne de commande et les alias
3. L’historique et le complètement avancé avec bash

Après ces trois billets plutôt sur la configuration de bash , passons aux choses sérieuses avec l’étude de trois concepts qui font du shell en général et de bash en particulier un outil extrêment puissant :

Les gestion des entrées/sorties (ou flux ou Input/Output ou I/O pour les intimes :) avec les redirections et l’utilisation du pipe.

1. Rediriger la sortie standard dans un fichier
2. Rediriger la sortie d’erreur dans un fichier
3. Rediriger la sortie standard et la sortie d’erreur sur la sortie standard
4. Et l’entrée standard ?
5. Pour aller plus loin
2. Les motifs (ie le globbing)

Les entrées/sorties

L’article sur les flux standards sur Wikipedia est une très bonne et courte introduction au concept d’entrée/sorties standards. Pour faire simple, lorsqu’un shell est lancé en mode interactif (ie le shell attend qu’on lui tape des commandes typiquement dans un terminal), l’entrée standard est le clavier et la sortie standard et la sortie d’erreur sont reliées au terminal. Par défaut, lorsque le shell lance une commande, cette commande hérite (entre autre) des entrées/sorties standards du shell parent. Ces flux sont manipulables dans le shell, quelques exemples pratiques à l’aide de la commande find permettant de rechercher tous les répertoires dans le dossier de l’utilisateur root sur lequel mon utilisateur n’a évidemment pas tous les droits, cette commande renvoie donc des informations sur la sortie d’erreur et la sortie standard :

Rediriger la sortie standard dans un fichier

Cette opération se fait avec l’opérateur >, qui créa le fichier si il n’existe pas ou l’écrasera avec la sortie standard en l’utilisant de la manière suivante :

Plutôt que d’écraser le fichier, il est aussi possible d’ajouter la sortie au fichier si celui-ci existe déjà avec l ‘opérateur >>.
Rediriger la sortie d’erreur dans un fichier

Cette opération se fait également avec > mais en spécifiant le descripteur de la sortie d’erreur (par défaut 2) :

Cette séquence est fréquemment utilisée pour n’afficher que la sortie standard en spécifiant comme fichier le fichier spécial /dev/null . De la même manière que précédemment, 2>> ajoutera la sortie d’erreur à la fin du fichier.
Rediriger la sortie d’erreur et la sortie standard sur la sortie standard

Ici, on souhaite tout avoir sur la même sortie pour un traitement ultérieur, pour cela il faut indiquer au shell de rediriger les données écrites sur le descripteur 2 sur le descripteur 1.

Et l’entrée standard ?

Il est possible d’enchâiner les commandes en redirigeant les sorties d’une commande sur l’entrée standard à l’aide du pipe (| ou tube), par exemple si je souhaite n’avoir que les messages concernant les dossier de GNOME à la suite de find, je peux utiliser l’utilitaire grep pour filtrer la sortie comme suit :

Comme vue précédemment, les sorties standard et d’erreur de find sont redirigés sur la sortie standard qui est elle même redirigées sur l’entrée standard de grep. Cette ligne est équivalente aux deux lignes suivantes utilisant le symbole < permettant de rediriger le contenu d'un fichier sur l'entrée standard :

elle même équivalente à

Ce sont des exemples très simples, mais il est possible ainsi de faire des choses assez complexe en une ligne en enchaînant quelques commandes (qui feront l’objet d’un prochaine billet) :

Cette ligne lit le fichier de log d’apache access.log et permet de compter le nombre de pages différentes vues au moment où j’écris ces lignes.

Pour aller plus loin

Pour en revenir aux entrée/sorties, ces opérations sont les plus courantes, mais il existe bien d’autres possibilités décrites dans la page du manuel de bash.

Les motifs

Les motifs sont des caractères spécifiques qui permettent, une fois développé par le shell, de remplacer plusieurs fichiers sans avoir à tous les écrire. Pour faire simple, ce sont des expressions rationnelles très limitées. Le plus connu de ces caractères est l’étoile * souvent utilisé dans les rm -rf * (ce qui est très dangereux !). Pour tester ces caractères, il vaut mieux utiliser echo.

À la suite des commandes tapées ci-dessus, j’ai plusieurs fichiers dans le répertoire temporaire qui peuvent servir d’exemple :

Pour utiliser l’un de ces caractères sur la ligne de commande sans qu’il soit interprèté, il suffit de la préfixer d’un antislash (\).

Le téléchargement et l’installation via apt:

La configuration:

L’ensemble des fichiers de configuration se trouve dans le répertoire /etc/munin:
* munin.conf : configuration du serveur
* munin-node.conf : configuration de l’agent
* plugin-conf.d : répertoire des fichiers de configuration des plugins
* plugins : répertoire des plugins activé ( la liste des plugins disponible se trouve dans /usr/share/munin/plugins)
* templates : modèles des pages web pour l’interface web

# Commençons par editer le « /etc/munin/munin.conf« , remplacez ces deux lignes par le domaine et l’ip de la machine a monitoré: (ici pour exemple c’est l’ip du serveur sur lequel vous naviguez)

Note: Vous pouvez inserer d’autres sous-domaines/serveurs a la suite, exemple: (ils sont juste ici a titre d’exemple.. et ne sont pas réels)

#Ensuite, occupons nous du « /etc/munin/munin-node.conf« :
Ajoutez l’ip de la machine autorisée a se connecter au ‘serveur’ Munin (si vous voulez simplement monitorer la machine sur laquelle vous allez creer les graphiques entrez ceci:

Pour prendre en compte les modifications.. on redémarre le node:

Dans mon cas, après l’installation les modifications n’ons pas été apportée aux fichiers config de apache (bug?) j’ai donc du creer une nouvelle configuration pour mes vHost:

On crée le fichier:

Et on y colle le code suivant.. modifié a votre sauce !

Terminez par Ctrl-D

Monitorer Apache:

(Version 2.x)

Editez « /etc/apache2/apache2.conf » puis décomentez ces lignes: (retirez les # en début de ligne)

On vérifie si la syntaxe est correcte:

On active le module status de apache (le script l’utilise pour récupérer les données qui serviront pour le graphique)

Et en recharge la nouvelle configuration:

Pour ce qui est de la config d’apache2, c’est terminé.. occupons nous de munin. Il faut maintenant activer les plugins – ons ne peut plus simple avec le système de liens a la apache 2.x !

et on relance:

(si vous avez des erreures, il se pourrais qu’il vous manque la librairie « libwww-perl » rien de plus simple pour l’installer:

Voila.. votre serveur est pret a etre monitoré comme jamais ;)

Ajout du 19 Mars 2007:

Les Plugins

Les plugins se trouvent dans « /usr/share/munin/plugins/ » .. mais attention, ils ne sont pas forcements actifs ! Pour qu’un plug-in soit actif il dois avoir un lien symbolique vers « /etc/munin/plugins/« , exemple avec le plugin apache_loadtime.

Mettez y a la fin:

Et enfin, redémarrez le munin-node