Guide avancé d'écriture des scripts Bash - Une exploration en profondeur de l'art de la programmation shell

Partie 1ère Partie. Introduction

1. Pourquoi programmer en Shell ?

Aucun langage de programmation n'est parfait. Il n'existe même pas de langage meilleur qu'un autre ; il n'y a que des langages plus ou moins en adéquation avec les buts qu'on se propose.

-- Herbert Mayer

Une connaissance fonctionnelle de la programmation shell est essentielle à tous ceux qui veulent devenir efficace en administration système, y compris ceux qui ne pensent pas avoir jamais à écrire de script. Il faut comprendre qu'au démarrage d'un ordinateur sous Linux, les scripts shell du répertoire /etc/rc.d sont exécutés pour restaurer la configuration du système et permettre la mise en fonctionnement des services. Une compréhension détaillée de ces scripts de démarrage est importante pour analyser le comportement d'un système et éventuellement le modifier.

Apprendre à écrire des scripts shell n'est pas difficile car, d'une part, les scripts sont souvent construits par petites sections et, d'autre part, il n'y a qu'un assez petit nombre d'opérateurs et d'options [1] spécifiques au shell à connaître. La syntaxe est simple et directe, semblable à une suite d'appels de différents utilitaires en ligne de commande et il n'existe que peu de « règles » à apprendre. La plupart des petits scripts fonctionnent du premier coup et le débogage, même des plus longs, est assez simple.

    
       Dans les années 1970, le langage BASIC
       permettait à toute personne qui s'y connaissait un peu en
       ordinateurs d'écrire des programmes sur les premières
       générations de micro-ordinateurs. Après plusieurs décades, le
       langage de script Bash permet à toute
       personne connaissant les rudiments du système Linux ou du
       système UNIX de faire la même chose, voire plus, sur des
       machines bien plus puissantes.
            

Écrire un script shell est une méthode « rapide et sale » de prototypage d'une application complexe. Avoir même un sous-ensemble limité de fonctionnalités dans un script shell constitue souvent une première étape utile lors d'un projet de développement. De cette façon, on peut tester la structure de l'application, la bricoler et ainsi détecter les problèmes les plus importants avant l'écriture du code final en C, C++, Java, Perl ou Python.

La programmation shell ramène à la philosophie classique des UNIX, de découper des projets complexes en sous-tâches plus simples et d'assembler des composants et les utilitaires. Beaucoup considèrent que cette approche de la résolution de problème est meilleure ou, du moins, plus abordable que l'utilisation de langages de nouvelle génération puissamment intégrés comme Perl, qui essaient de tout faire pour tout le monde mais au prix de vous forcer à changer votre processus de réflexion pour vous adapter à l'outil.

D'après Herbert Mayer, « un langage utile doit comprendre des tableaux, des pointeurs et un mécanisme générique pour construire des structures de données. » Suivant ces critères, les langages des scripts shell ne sont pas « utiles ». Enfin, peut-être que si...

Quand vaut-il mieux ne pas utiliser les scripts shell ?

  • pour des tâches demandant beaucoup de ressources, surtout lorsque la rapidité est un facteur important (tri, hachage, récursion [2] ...) ;

  • pour des procédures impliquant des opérations mathématiques nombreuses et complexes, en particulier l'arithmétique à virgule flottante, les calculs à précision arbitraire et les nombres complexes (optez plutôt pour C++ ou FORTRAN dans ce cas) ;

  • pour une portabilité inter-plateformes (utilisez le C ou Java à la place) ;

  • pour des applications complexes où une programmation structurée est nécessaire (typage de variables, prototypage de fonctions, etc.) ;

  • pour des applications critiques sur lesquelles vous misez l'avenir de votre société ;

  • pour des situations où la sécurité est importante, où vous avez besoin de garantir l'intégrité de votre système et de vous protéger contre les intrusions et le vandalisme ;

  • pour des projets consistant en de nombreux composants avec des dépendances inter-verrouillées ;

  • lorsque des opérations importantes sur des fichiers sont requises (Bash est limité à un accès fichier en série, ligne par ligne, ce qui est particulièrement maladroit et inefficace) ;

  • si le support natif des tableaux multidimensionnels est nécessaire ;

  • si vous avez besoin de structures de données telles que des listes chaînées ou des arbres ;

  • si vous avez besoin de générer ou de manipuler des graphiques ou une interface utilisateur (GUI) ;

  • lorsqu'un accès direct au hardware ou aux périphériques externes est nécessaire ;

  • lorsque vous avez besoin d'accéder à un port, à un socket d'entrée/sortie ;

  • si vous avez besoin d'utiliser des bibliothèques ou une interface propriétaire ;

  • pour des applications propriétaires, à sources fermés (les sources des shells sont forcément visibles par tout le monde).

Si vous vous trouvez dans l'un des cas ci-dessus, pensez à utiliser un langage de scripts plus puissant, peut-être Perl, Tcl, Python, Ruby, voire un langage compilé tel que C, C++ ou Java. Cependant même dans ce cas, prototyper l'application avec un script shell peut toujours être une étape utile du développement.

Nous utiliserons Bash, un acronyme [3] pour « Bourne-Again shell » et un jeu de mots sur le désormais classique Bourne shell de Stephen Bourne. Bash est devenu le standard de facto pour la programmation de scripts sur la plupart des systèmes UNIX. La plupart des principes discutés dans ce livre s'appliquent également à l'écriture de scripts avec d'autres shells tels que le Korn Shell, dont dérivent certaines des fonctionnalités de Bash, [4] , le shell C et ses variantes (notez que la programmation en shell C n'est pas recommandée à cause de certains problèmes intrinsèques, comme l'indique Tom Christiansen sur un message Usenet d'octobre 1993).

Ce qui suit est un tutoriel sur l'écriture de scripts shell. Il est en grande partie composé d'exemples illustrant différentes fonctionnalités du shell. Les scripts d'exemple ont été testés autant que faire se peut, et certains d'entre eux peuvent même être utiles dans la vraie vie. Le lecteur peut jouer avec le code des exemples dans l'archive des sources (nom_script.sh ou nom_script.bash), [5] leur donner le droit d'exécution (chmod u+rx nom_du_script) et les exécuter pour voir ce qui se passe. Si les sources ne sont pas disponibles, alors copiez/collez à partir de la version HTML ou PDF. Sachez que certains scripts présentés ici introduisent des fonctionnalités avant qu'elle ne soient expliquées, ce qui peut réclamer du lecteur de lire temporairement plus avant pour des éclaircissements.

Sauf mention contraire, l'auteur de ce livre a écrit les scripts d'exemples qui suivent.

His countenance was bold and bashed not.

--Edmund Spenser


[1] Ces opérateurs et options sont appelés commandes intégrées, c'est-à-dire des fonctionnalités internes au shell.

[2] Bien que la récursion soit possible dans un script shell, elle tend à être lente et son implémentation est souvent le résultat d'un code sale.

[3] Un acronyme est un mot formé par le collage des initiales des mots d'une expression qui fait fourcher les langues. C'est une pratique subversive qui mérite certainement un châtiment sévère.

[4] Beaucoup de fonctionnalités de ksh88, et même quelques unes de la version mise à jour ksh93, ont été intégrées à Bash.

[5] Par convention, les scripts shell écrits par l'utilisateur, compatibles avec le shell Bourne, sont nommés avec l'extension .sh. Les scripts système, tels que ceux trouvés dans /etc/rc.d, ne suivent pas cette nomenclature.