L'objet de ces Travaux Dirigés est d'initier (pour certains ou approfondir pour les autres) les étudiants de Licence Professionnelle AdmiSys, aux techniques de scripts afin de leur permettre d'envisager un certain degré d'automatisation des taches d'administration.
Les notions de base seront dans un premier temps envisagées dans un environnement Unix-like, mais pourront être extrapolées vers les systèmes Windows™ plus ou moins récents (des traitements batchs originaux de DOS aux touts récents scripts Windows Power Shell™ à partir de Windows 2008 Server™).
Quoi qu'il en soit, la majeure partie de ces T.D. portera sur l'étude des possibilités de scriptage offertes par le shell Unix (et plus précisément le shell bash, maintenant shell par défaut de la plupart des distributions Linux) et des principales commandes de base disponibles sur ces systèmes.
Pour conclure cette courte introduction, voici quelques arguments pour se convaincre de l'utilité du scripting, et ce même dans le cadre d'une formation d'administrateurs de réseaux, par essence éloignés, voire allergiques à toute forme de programmation :
- Le premier point est tout simplement historique : utiliser la ligne de commande fût longtemps la seule possibilité de communication avec la machine (soit après la carte perforée, et avant les terminaux graphiques). Dès lors, automatiser des tâches journalières pouvait apparaître comme une belle avancée. A l'identique, un serveur Unix-like n'a aucun besoin d'interface graphique pour exécuter nombre de services [1] ; ou sera hébergé à distance dans un "DataCenter", l'accès via une interface graphique devenant de ce fait compliquée... ou du moins très ralentie ! Il faut également bien garder en mémoire que les applications graphiques en environnement Unix (du moins celle bien écrites !) ne servent jamais qu'à générer syntaxiquement une "commande" qui sera finalement exécutée de façon cachée à l'utilisateur...
- Ensuite, bien que quelques tâches (créer un utilisateur, par exemple) puissent être rapidement affectuées via un outil graphique, si l'on doit les réaliser répétitivement un très grand nombre de fois, celà devient vite fastidieux ; et l'on s'aperçoit que les interfaces graphiques ne sont plus adaptées à cette nouvelle problématique.
En conclusion, ne vaut-il mieux pas perdre (une fois pour toutes) un peu de temps à mettre au point un script, que perdre souvent du temps à répéter une même action ?
Avant d'envisager les scripts-shells d'un point de vue purement technique, il convient également d'en cerner l'évolution historique et les (in)compatibilités qui en découlent.
Au début fût le Bourne Shell (sh), écrit au sein des laboratoires AT&T, dans les années 1970 par Steve Bourne. Ce programme sert donc à lancer interactivement des commandes, mais il est également déjà doté de possibilités de programmation.
A peu près à cette même période, Bill Joy [2] écrit pour sa part le C-shell (csh) qui s'avère incompatible avec le Bourne Shell, mais est doté de capacités supplémentaires, telles que l'historisation des commandes, les alias ou encore le contrôle des tâches. Ce shell équipa par défaut les systèmes *BSD, puis fût remplacé par le plus récent Tenex C-Shell (tcsh) dans les versions ultérieures de ces systèmes d'exploitation, mais qui finiront par adopter malgré tout le shell bash.
Il faut attendre 1983 pour commencer à voir la nouvelle génération d'interpréteurs de commandes ; qui voit le jour sous la paternité de David Korn et prendra donc le nom de Korn Shell (ksh). Ce nouveau shell est basé sur l'historique Bourne Shell, lui ajoutant nombre des nouvelles fonctionnalités faisant le succès du C-shell, et prenant ainsi une place prépondérante au palmarès des interpréteurs de commande pour Unix ; à tel point qu'il en deviendra le standard de fait.
En 1988, David Korn en sort une nouvelle révision, le ksh 88 qui servira de base à la normalisation du shell (norme IEEE Posix 1003.0). En 1993, une dernière version est publiée, le ksh 93, c'est un sur-ensemble de la norme POSIX, permettant notamment de manipuler des nombres flottants et des tableau associatifs.
Au milieu des années 1990, la Free Software Foundation propose quant à elle sa propre version du Bourne Shell, dénommée Bourne Again Shell (bash), qui est conforme au standard édicté par la norme POSIX, tout en offrant quelques extensions. Le shell bash est actuellement l'interpréteur fourni en standard par les distributions Linux : c'est donc particulièrement sur celui-ci que portera notre étude.
Il découle de ce court historique que les scripts initialement écrits pour le C-Shell et ceux pour le Bourne Shell seront par essence incompatibles entre eux, impliquant un portage plus ou moins important selon les fonctionnalités utilisées.
Par contre, les scripts écrits pour ksh (du moins ceux n'utilisant pas les fonctionnalités introduites dans la version de 1993) seront à priori compatibles avec le shell bash, et dans une moindre mesure le bourne shell originel ; seules quelques fonctions avancées ne seront pas reconnues (par exemple la commande printf de bash.
| [1] | D'aucuns pourraient même considérer qu'il s'agit là d'une pure perte de ressources (en temps processeur et occupation mémoire)... |
| [2] | Principal responsable des publications de l'Unix Berkeley (donc de ce qui deviendra la famille des *BSD) et co-fondateur de Sun MicroSystems™. |
| Suivant | ||
| Les Fondements : descripteurs de fichiers par défaut, redirections et pipes |