En temps qu'enseignant d'IUT informatique, je suis amené à faire découvrir aux futurs informaticiens de notre nation les rudiments de la ligne de commande au travers d'un cours appelé « UNIX : système utilisateur ». Ce cours est l'occasion d'une rupture entre le monde convivial mais peu performant de l'environnement graphique tel que tout utilisateur le connaît et le monde obscure mais tellement inintéressant de l'informaticien où la ligne de commande est reine et l'ordinateur enfin dompté. C'est en quelque sorte un premier pas vers ce qui sera l'environnement futur de l'informaticien.
Durant ces années d'enseignement, j'ai parfois eu du mal à convaincre de jeunes étudiants que la ligne de commande était un point de passage nécessaire. Je n'y suis pas toujours arrivé et je n'y arriverai sans doute pas plus à l'avenir, mais le temps et l'expérience travaillent sans doute pour moi.
Pourquoi écrire ce petit ouvrage ? Simplement car mes paroles en cours s'envolent et la prise de note semble un art en voie de disparition. Alors peut être que les écrits resteront. Et si vous me demandez en quoi est-il important que les écrits restent, je vous répondrai simplement en prenant ma seconde casquette : celle d'un professionnel du secteur privé qui dans son activité croise chaque jour le résultat du travail de ces jeunes maintenant diplômés. Sous cette casquette je constate avec quelle difficulté ils ont du mal, trois ou quatre ans après, à écrire un simple script. Je vais illustrer cela par un exemple qui me tient à coeur.
Je travaille dans un domaine que l'on appelle la « Supply Chain » : il s'agit de déplacer les produits fabriqués par les usines dans les bons magasins de sorte à ce qu'ils soient disponibles au bon endroit et au bon moment pour nos clients. Vous l'aurez compris, ce genre de programme n'est pas de ceux qui s'installent sur un simple ordinateur personnel. Ils ne sont pas non plus constitués d'un unique programme autonome. Il s'agit en fait d'une constellation de programmes composites, basés sur des progiciels et de multiples technologies. Pour vous donner une idée plus précise, un tel programme demande environ 100 jours pour être installé sur un serveur... Ce type de programme, finalement très banal en entreprise, est constitué de nombreux scripts et fonctionne sur un environnement UNIX.
Pour en revenir à mon illustration, au sein de cette application demeure un script qui m'a particulièrement interpelé, ce script exécute un traitement très simple : s'assurer que la dernière ligne d'un fichier texte est bien « fin fichier ». Il permet alors de vérifier que le fichier est bien arrivé dans son intégralité avant de le passer au programme suivant qui le chargera ligne par ligne dans la base de données. Lorsque j'ai eu a faire pour la première fois à ce script, j'ai découvert, non seulement qu'il faisait pas loin de 200 lignes mais qu'en plus il ne fonctionnait pas en renvoyant toujours vrai, que le fichier se termine ou non par « fin fichier ». Il y a donc ici deux problèmes, le premier est bien sûr que le programme ne fonctionne pas et donc qu'il n'a pas été testé, mais en plus, un tel programme ne devrait demander qu'une seule et unique ligne de script pour répondre au cahier des charges...
Qu'est-ce que cela signifie ? D'un point de vue économique, l'écriture de ces 200 lignes de scripts ne fonctionnant pas a dû coûter à mon employeur quelque chose comme 500 €, mais le plus grave et le plus dur à estimer est l'impact que ce script a sur la production au jour le jour : nous pouvons considérer que les impacts de ce non fonctionnement ont coûté une demi-journée de travail et des retards dans l'exécution de l'application chaque fois qu'un fichier est arrivé incomplet. C'est donc au final plusieurs milliers d'euros que ce script aura coûté... quelques mois de salaire d'un informaticien débutant et plein de cheveux en moins pour ceux qui subissent ce script. Car bien sûr un tel bug met un peu de temps à être corrigé car il ne se déclenche pas toujours et les problèmes n'apparaissent qu'en aval du programme, lorsque des données incomplètes sont chargées.
Cet exemple, un peu long, a pour but de rappeler aux lecteurs qu'en entreprise les bugs coûtent des mois de salaires, d'une part, et pour les inciter à se référer à cet ouvrage ou tout autre, s'ils étaient dans la situation, au cours de leur carrière, de devoir écrire un script shell alors qu'ils n'auraient plus trop en mémoire cette matière...
Unix a l'intérêt d'être un standard et de garantir ainsi un environnement de travail offrant des caractéristiques définies. Ces caractéristiques assureront la compatibilité de logiciels par exemple et permettront à l'utilisateur une certaine indépendance vis à vis de son fournisseurs. UNIX, outre la percée de Linux dans des environnements utilisateur est un système principalement à destination des serveurs ou des stations professionnelles dédiées aux calculs ou la CAO.
UNIX est ce que l'on appelle un Système d'Exploitation, tout comme peut l'être Windows.
S'il n'existe qu'un seul Windows (aux versions près), il existe de multiples UNIX. UNIX est donc plus un standard qu'un système en tant que produit. On appelle les Systèmes d'Exploitation SE ou OS comme Operating System, le terme anglais étant plus couramment utilisé.
Un système d'exploitation est un logiciel dont le rôle est de simplifier l'accès au matériel pour les applications qui seront lancées par les utilisateurs. C'est ainsi qu'il gère les composants d'un ordinateur comme la mémoire, le stockage des fichiers, les périphériques son ou réseau. L'OS est donc un élément très proche et bien spécifique à un matériel donné. Nombre de fabriquants de matériel possèdent donc leur propre système qu'ils livrent avec leurs ordinateurs.
Dans ses autres missions, le système d'exploitation gère aussi les utilisateurs et ainsi l'ensemble des droits que peut avoir un utilisateur sur l'ordinateur. Il est ainsi possible de décider de répertoires que l'utilisateur ne pourra pas consulter ou d'interdire à certains l'usage de la carte son...
Un système d'exploitation offre aussi aux développeurs des bibliothèques de fonctions permettant par exemple la lecture et l'écriture de fichiers. Des exemples plus étendus couvrent par exemple l'utilisation de capacités graphiques avancées. C'est le cas de DirectX, un environnement de programmation intégré au système qui s'adapte aux cartes graphiques présentes dans votre PC pour en utiliser au mieux les capacités. Cette bibliothèque offre aux développeurs de jeux vidéo un ensemble de fonctions rendant la conception de jeux 3D bien plus simple et leur assure que leur développement fonctionnera quel que soit le matériel de l'utilisateur.
L'utilisation d'un système d'exploitation est une évolution majeure de l'informatique, au tout début de l'histoire de nos ordinateurs, ceux-ci n'en possédaient donc pas. Un ordinateur sans système d'exploitation peut être comparé aux premières consoles que certains ont peut-être connues... celles où rien ne se passe si vous n'insérez pas la cartouche adéquat contenant le jeu.
Une machine sans OS n'est constituée que d'éléments matériels et n'a donc rien à exécuter, l'utilisateur devra donc y insérer un programme pour que quelque chose se passe et seul ce programme fonctionnera. En outre, ce programme n'ayant pas d'OS devra par lui-même intégrer toutes les fonctionnalités d'accès au matériel, il ne fonctionnera, par conséquent, que sur un matériel 100% identique. Avantage toutefois de ce système, le programme 100% étudié pour une architecture donnée peut utiliser au mieux les capacités du matériel.
De très nombreux systèmes informatiques d'aujourd'hui tournent encore sans système d'exploitation, ils ne font toutefois pas partie des systèmes conventionnels tels que vous les imaginez mais des systèmes embarqués, beaucoup plus nombreux. Ces systèmes sont basés sur des micro-contrôleurs (sortes de systèmes informatiques miniaturisés) et se trouvent dans les objets du quotidien comme les téléviseurs, voitures, plaques de cuisson...
Les systèmes d'exploitation n'apparaissent que vers la fin des années 60 alors que le besoin de partager un même ordinateur à plusieurs se fait sentir. En effet, les équipements de l'époque coutent quelques millions de dollars et la superficie leur étant nécessaire couvre quelques centaines de mètres carrés. Pas question, donc, d'en posséder plusieurs. Il est donc nécessaire de les partager.
Partager un ordinateur signifie être capable de lancer plusieurs programmes en même temps, par exemple, ce qui, nous l'avons vu, n'est pas possible sans un élément logiciel créant cette fonctionnalité. Partager un ordinateur signifie aussi gérer des utilisateurs, leur accorder des privilèges ou non. Ainsi sont nés les premiers systèmes d'exploitation, tout d'abord MULTICS puis UNICS dans les célèbres laboratoires d'AT&T (Bell Labs) puissante entreprise de recherche à l'époque. UNICS sera mono-utilisateur mais multi-tâches (il pourra exécuter plusieurs programmes en même temps). Il deviendra rapidement UNIX et évoluera jusqu'à une version 6 qui sera donnée aux universités et entreprises en 1977.
De ce don se créent plusieurs branches dont la première celle de Berkley (BSD) en 1978.
Microsoft ne sera pas en reste en proposant XENIX en 1980, OS a la vie plutôt courte, disparaissant cinq ans plus tard. De nombreuses autres branches vont apparaître : chaque constructeur de matériel proposant sa version, adaptée à ses serveurs. Ainsi, HP propose HP-UX, IBM AIX, SUN, SUNOS/SOLARIS, Silicon Graphics IRIX ...
En parallèle de ces UNIX apparaissent d'autres systèmes profitant des nouvelles niches offertes par l'informatique personnelle, niches devenant ce que vous en connaissez aujourd'hui. Les acteur de ce marché sont Microsoft et Mac. D'autre tenteront en vain de s'y installer : BeOs du Français Gasnier ou Next de Steve Jobs, échappé quelque temps de la firme à la pomme. Ce seront des échecs : le marché est tenu. Il n'est pas d'ordinateurs vendus sans système pré-installé issu de l'un des deux majeurs.
Le seul système qui parviendra à percer ce monopole, avant de convaincre et de s'étendre aux serveurs sera GNU/Linux. Il s'imposera par sa qualité et sa gratuité avant de séduire par ses fonctionnalités qui aujourd'hui n'ont plus grand chose à envier aux systèmes commerciaux.
GUN/Linux n'est une branche d'aucun autre UNIX, il aura été développé de rien par son auteur
Linus Torwalds en 1991 ; de là naîtront de multiples distributions : Red-Hat, OpenSuse... Une distribution est un assemblage spécifique de composants tous identiques.
Une distribution est un noyau (le coeur d'un OS) appelé ici Linux, associé à de nombreux programmes tels que le compilateur C, un environnement en ligne de commande et des outils divers qui sont eux issus de l'initiative GNU de la Free Software Fundation. C'est ainsi que les deux termes doivent être associés GNU/Linux. GNU travaille de son côté à la réalisation de son propre noyau :
HURD.
En entreprise, les systèmes UNIX étant les plus nombreux et l'environnement de Windows n'ayant rien de très intéressant à nous apprendre, ce sont ces premiers que nous allons étudier dans les chapitres à venir.
La ligne de commande, pour certains, semble être un bond dans les temps préhistoriques vis à vis des interfaces graphiques riches que connaissent les utilisateurs d'aujourd'hui. C'est cependant une vision totalement fausse de l'évolution informatique lorsque l'on prend en considération le fait que même Microsoft, sentant la baisse de ses ventes, prévoit dans ses versions serveurs un environnement en ligne de commande étendu.
L'environnement en ligne de commande n'est sans doute pas des plus agréables lorsqu'il s'agit de lancer des applications, copier des fichiers (bien que...) mais c'est en tout cas le seul où il soit possible d'automatiser et de répéter des opérations à réaliser régulièrement. Ce n'est donc sans doute pas l'outil idéal pour l'utilisateur mais bien l'outil le mieux adapté à l'informaticien, particulièrement dans des métiers tels que ceux de l'exploitation.
La ligne de commande ou plus précisément la programmation shell offre un environnement de développement très efficace lorsqu'il s'agit de manipuler des fichiers, autant pour les déplacer, renommer... que pour les traiter : trier, découper, rechercher...
Ce sont les possibilités de cet environnement que nous allons étudier au fur et à mesure des chapitres à venir, par l'utilisation des environnements de type UNIX.
Le Shell est un programme interagissant avec l'utilisateur, il possède ainsi une entrée qui est par défaut le clavier et une sortie par défaut : l'écran. L'utilisateur peut y saisir des commandes qui seront exécutées par le système. Il existe de nombreux shells. Celui qui sera couramment utilisé sous Linux est le BASH, le Shell SH est le shell le plus basique, il assurera la compatibilité des scripts que vous écrirez. Il existe de nombreux autres shell comme le KSH, CSH, TCSH ...
Un shell est un programme comme un autre, il est ainsi possible de lancer un shell en tapant son nom alors que vous en utilisez un autre.
Outre le lancement de commande, un shell intègre un langage de programmation avec la prise en compte de conditions et de boucles, la gestions de variables... tout comme le fait le C par exemple.
Pour notre premier exemple nous allons réaliser le plus classique des programmes, le Hello
World, consistant à afficher à l'écran cette simple phrase. La commande shell permettant d'afficher quelque chose est echo ainsi, pour réaliser cet affichage, nous taperons simplement la commande suivante :
[email protected]:/tmp/> echo Hello World
Le résultat apparaîtra sur la ligne suivante.
Les commandes shell sont très nombreuses et chacune possède de multiples options. Pour en percer le mystère, il existe quelques commandes très utiles : le manuel man ou info qui nécessite de connaître le nom de la commande que l'on souhaite détailler. Les recherches par fonctionnalités se font en utilisant apropos.
Ainsi pour tout savoir des options de la commande echo que nous venons de voir, il suffit d'exécuter la commande man echo. Une page de manuel s'affichera alors. La touche q permet de sortir de l'éditeur.
La recherche de fonctions permettant la copie de fichiers pourra se faire par l'appel à la commande apropos ''copier des fichiers'' qui vous indiquera de consulter les commande cp ou install.
Une dernière façon d'obtenir des informations sur l'usage d'une commande est d'utiliser l'aide intégrée à la commande elle même, souvent accessible par une option spécifique : --help.
Cette façon de faire n'est toutefois pas standardisée et ne fonctionnera donc pas toujours.
Une commande est généralement un programme qui va être exécuté pas le shell. Cette commande, comme nous l'avons vu prend des paramètres. Les paramètres sont séparés par des espaces. Ainsi echo Hello World correspond à l'exécution de la commande echo avec comme premier paramètre Hello et comme second World. Il est possible de réunir ces deux mots en un seul
paramètre en les plaçant entre double quotte « '' ». Ce qui pour cette commande ne change rien mais pour d'autres sera primordial.
Certains paramètres sont particuliers et appelés options. Les options sont généralement précédées d'un « - » ou d'un « -- » . Les options changent le comportement du programme. Les options sont généralement facultatives.
La façon dont doit être utilisée une commande est décrite dans sa documentation, prenons l'exemple de echo et de ce que nous dit son manuel :
NAME
echo -- write arguments to the standard output
SYNOPSIS
echo [-n] [string ...]
echo est donc une fonction écrivant la liste de ses arguments sur la sortie standard (comme nous l'avons vu). Cette fonction prend comme argument une liste de chaînes des caractères : indiquée par string et ... qui nous indique que tous les arguments suivants seront considérés comme le précédent à savoir des chaînes de caractères à afficher. echo peut recevoir une option ici -n ; qui (et c'est indiqué plus loin dans le manuel) sert à ne pas ajouter de retour charriot en fin de ligne. Les arguments comme l'option sont notés entre « [] » ce qui signifie qu'il sont facultatifs. Il est donc possible d'appeler la commande echo, sans rien indiquer de plus, sans que cela provoque une erreur. Si les arguments ne sont pas entourés de crochets, ils sont alors obligatoires sans quoi la commande retournera une erreur.
Il est possible d'enchaîner plusieurs commandes en les séparant par un retour charriot ou par le caractère « ; ». L'exécution est dans ce cas séquentielle – la commande suivante commencera après la fin de la précédente.
Les commandes peuvent êtres inscrites dans un fichier plutôt que d'être tapées dans la console, on parlera alors de scripts. Un script est un programme, exactement comme l'est un programme écrit en C, à la différence qu'un programme shell n'est pas compilé mais simplement interprété. En exemple, voici votre premier programme shell, le programme helloWorld :
#!/bin/sh
echo ''Hello World !''
Ce contenu sera enregistré dans un fichier texte du nom de helloWorld et pourra être exécuté simplement de la façon suivante : sh ./helloWorld
La première ligne du fichier indique quel shell doit être utilisé pour son exécution, les lignes suivantes représentent simplement un enchaînement de commandes comme vous les taperiez dans la console.
Nous verrons par la suite qu'il existe d'autres moyens d'exécuter ce même script et comment lui permettre d'utiliser des paramètres.
