Capsule : Shell, interface en ligne de commande et terminal

Introduction

Lorsque l’on parle d’administration système et de la réalisation de script dans ce domaine, on en vient inévitablement à parler de shell, d’interface en ligne de commande (command line interface, CLI) et de terminal. Dans la plupart des cas, ces termes sont utilisés de manière interchangeable pour désigner l’interface utilisateur en ligne de commande du système d’exploitation, qui apparaît dans une fenêtre de l’émulateur de terminal comme dans l’image de la figure 1.

Fig. 1 – Fenêtre de l'émulateur de terminal de Gnome
Fig. 1 – Terminal Gnome sous Debian 8

Un autre terme qui revient souvent dans le contexte de l’administration système est celui de fichier batch. Ce terme fait référence à un script écrit dans le langage de commande de Windows. Le mot batch vient du fait qu’un tel script est très souvent un programme qui fonctionne selon le principe du traitement par lot (batch processing), c’est-à-dire sans interactions avec l’utilisateur.

Les lignes qui vont suivre ont pour but d’expliquer ces notions en les resituant dans un contexte historique.

Traitement par lots et traitement en ligne

On distingue au moins deux manières d’utiliser un ordinateur. L’une est celle héritée du traitement mécanique des données (mécanographie), et consiste à fournir à la machine un lot de données à traiter, la laisser travailler et récupérer le résultat lorsqu’elle a terminé. C’est ce qu’on appelle le traitement par lots (batch processing). L’autre, à laquelle nous sommes habitués, se nomme traitement en ligne (online processing) et consiste à utiliser l’ordinateur de manière interactive.

Après la Première Guerre mondiale et jusqu’à la fin des années cinquante, les ordinateurs de première génération sont extrêment coûteux. De plus, leur mémoire très limitée ne peut contenir qu’un seul programme. Comme le chargement d’un programme à partir de la console est une procédure relativement longue, on planifie les tâches de manière à maximiser le temps durant lequel l’ordinateur traite effectivement des données. Ces tâches, qui se présentes sous forme de piles de cartes perforées, sont donc regroupées en lots (batch) qui sont ensuite lancés selon la planification par un opérateur de console (seul habilité à le faire). Le traitement d’un lot s’effectue sous la surveillance de l’opérateur, mais sans intervention de l’utilisateur. Des tâches particulières comme la compilation des programmes ne sont exécutées que durant les heures creuses, souvent la nuit.

Fig. 2 – Une technicienne charge un programme à l’aide du lecteur de cartes perforées sur un IBM 709 (fin des années 1950)
Fig. 2 – Une opératrice charge un programme à l’aide du lecteur de cartes perforées à côté de la console d’un IBM 709. La console permet de suspendre l’exécution du programme
et de manipuler la mémoire de l’ordinateur.

Au début des années 1960, l’arrivée de systèmes à temps partagé (time sharing systems) qui permettent l’exécution simultanée de plusieurs programmes et l’apparition de nouveaux ordinateur, plus petits et beaucoup moins coûteux (en 1959, un PDP-1 est vendu 120’000 $, l’équivalent d’un million de dollars actuels, à peine deux mois de loyer d’un IBM 709), rendent possible la réalisation d’applications interactives. Comme on interagit avec ces programme à l’aide d’un terminal relié à l’ordinateur par une ligne de transmission, on désigne cette nouvelle façon d’utiliser un ordinateur « traitement en ligne » (online processing) alors que la manière traditionnelle est désormais appelée « traitement par lots » (batch processing).

Aujourd’hui, à quelques exceptions près (notamment certains clusters de calcul), on utilise les ordinateurs principalement de manière interactive soit à travers une interface graphique soit à l’aide d’une interface en ligne de commande. Le terme batch processing est toujours utilisé, mais désigne simplement le mode de fonctionnement d’un programme qui ne nécessite pas d’interaction avec l’utilisateur (voir encadré).

De nos jours, les interfaces à manipulation directe sont, en apparence du moins, le moyen le plus courant d’interagir avec un programme. C’est ce que nous utilisons sous Windows, macOS, Gnome, iOS et Android. Ce type d’interface communément appelée interface utilisateur graphique (graphical user interface ou GUI) permet de manipuler des objets tels que fichiers, éléments d’image, ou paragraphes d’un texte, directement à l’aide d’un dispositif de pointage comme une souris ou un écran tactile. Le principal avantage de ce mode d’interaction est sa prise en main aisée qui permet à un utilisateur débutant ou occasionnel d’effectuer une tâche de manière relativement efficace. En revanche, la manipulation directe peut rapidement s’avérer fastidieuse pour un utilisateur expert et n’est que peu adaptée à l’automatisation.

Une autre façon d’interagir avec un programme consiste à lui envoyer des ordres sous forme de texte à l’aide d’une ligne de commande interactive. Certaines applications fournissent cette ligne de commande au sein de leur interface graphique ; c’est par exemple le cas du logiciel AutoCAD et de certains éditeurs de texte, comme Emacs, Atom ou Visual Studio Code. Le plus souvent, cependant, l’interface utilisateur en ligne de commande (CLI) est la seule disponible et le programme nécessite l’utilisation d’un terminal ou d’un émulateur de terminal. Parmi les nombreuses applications de ce type, on peut citer le CLI d’un serveur de base de données et bien sûr, le shell de votre système d’exploitation.

La grande facilité avec laquelle on peut automatiser un CLI constitue sans doute son plus grand avantage. En effet, pour autant que les commandes puissent s’exécuter sans interaction avec l’utilisateur, on peut aisément les assembler dans un fichier de texte et remplacer le flux de données du clavier par les caractères de ce fichier (voir Redirection des entrées-sorties). On utilise cette propriété des CLI non seulement pour écrire un script Bash ou un « batch » sous Windows, mais également pour charger la configuration d’un routeur ou d’un pare-feu, ou encore pour exécuter un script SQL.

Enfin, on peut également inclure par extension dans cette catégorie d’applications, les programmes qui implémentent la partie serveur de protocoles de communication tels que le HTTP, le FTP ou SMTP. En effet, ces protocoles sont conçus pour permettre la communication entre deux machines, mais rien ne nous empêche d’utiliser un terminal pour leur envoyer des commandes et recevoir leurs réponses.

Fig. 3 – Session HTTP dans un émulateur de terminal
Fig. 3 – Session HTTP dans un émulateur de terminal

TTY, terminal vidéo et émulateur de terminal

Comme nous l’avons vu, les ordinateurs des années cinquante n’étaient pas utilisés de manière interactive. L’échange de données avec l’ordinateur se faisait au moyen de cartes perforées du même type que celles utilisées depuis deux décennies pour la mécanographie, toujours bien présente à cette époque.

Si les cartes perforées sont parfaitement adapté au traitement par lots, il ne l’est en revanche pas du tout au traitement en ligne. Il fallait un moyen d’envoyer des données immédiatement à l’ordinateur. Pour cela, un appareil bien connu à l’époque puisqu’on l’utilise depuis les années trente pour la transmission de messages sur le réseau Télex, semble tout désigné : le téléscripteur (teletype ou TTY).

Sur l’image de la figure 4 prise en 1972, on peut voir Ken Thompson (assis) connu pour avoir conçu et réaliser la première version d’Unix et Dennis Ritchie, inventeur du langage C et coauteur du livre au titre éponyme.

Ken Thompson (sitting) and Dennis Ritchie at PDP-11
Fig. 4 – Ken Thompson (sitting) and Dennis Ritchie at PDP-11,
Peter Hamer, via Wikimedia Commons

La rangée d’armoires qui se trouve à l’arrière-plan rassemble les différents éléments et périphériques de l’ordinateur DEC PDP-11 sur lequel travaillent les deux hommes. Thompson est assis à un pupitre sur lequel se trouve une sorte de machine à écrire ; il s’agit du téléscripteur qui lui permet d’interagir avec l’ordinateur à travers une ligne de communication série. Comme cet appareil se trouve à l’extrémité de la ligne, il est également appelé terminal en ce sens qu’il termine la ligne. En visionnant la vidéo de la figure 5, vous pourrez voir ce dispositif en action.

Fig. 5 – Téléscripteur en action

Le principe de fonctionnement est le suivant : lorsque l’opérateur appuie sur une touche, le terminal imprime le caractère, avance le chariot et envoie le code de caractère correspondant sur la ligne sérielle. De l’autre côté de la ligne, le programme reçoit les codes de caractères et les interprètes. Lorsque le programme veut imprimer un message, il envoie à son tour le code de chaque caractère sur la ligne de transmission, le terminal les reçoit et effectue pour chacun d’eux l’opération correspondante (imprimer le caractère, revenir à la ligne, activer la cloche, etc.). Le terminal et le programme doivent impérativement se référer à la même norme d’encodage. Dans le cas du Teletype Model 33 de la photo et de la vidéo, il s’agit du code ASCII, mais d’autres terminaux peuvent utiliser d’autres normes d’encodage (voir Encodage de caractères et fichiers de texte).

Du début des années soixante à la moitié des années septante, le téléscripteur constitue le moyen le plus courant pour communiquer avec un ordinateur. Mais durant la seconde moitié des années septante, même s’ils restent très présents, on voit apparaître à leurs côtés un autre type de terminal que l’arrivée de microprocesseurs bon marché tels que le 8080 d’Intel rend désormais plus abordable : le terminal vidéo. Dans ces appareils, le rouleau de papier et l’imprimante font place à un écran à tube cathodique. L’image de la figure 6 montre un VT100 de 1978.

Terminal DEC VT100
Fig. 6 – Terminal DEC VT100, Jason Scott, via Wikimedia Commons

Le principe reste le même — il s’agit toujours d’imprimer et d’envoyer sur la ligne les caractères que l’utilisateur tape au clavier, et d’imprimer les caractères qui viennent de la ligne — et on les appelle toujours TTY, mais les terminaux vidéo offrent un bien meilleur confort d’utilisation. En effet, les téléscripteurs sont des machines électromécaniques qui ne permettent de travailler que sur une seule ligne (l’éditeur ed est un vestige de cette époque). Les terminaux vidéo quant à eux sont de petits micro-ordinateurs (le VT100 est équipé d’un microprocesseur Intel 8080, identique à celui de l’Altair 8800) qui permettent notamment de supprimer des caractères à l’écran et de déplacer le curseur d’insertion. Ces nouvelles possibilités ont permis aux éditeurs de texte vi et Emacs de voir le jour en 1976.

Vers la fin des années huitante, la distribution à large échelle de micro-ordinateur compatible PC à bas prix a progressivement sonné le glas des terminaux vidéo. En effet, pour connecter un terminal à un ordinateur, on doit juste disposer d’un port série (RS-232). Comme ce type d’interface était standard sur les PC de l’époque, il ne restait qu’à réaliser un programme permettant au micro-ordinateur de se comporter comme un terminal vidéo : un émulateur de terminal.

Pour diverses raisons, les interfaces en ligne de commande ne sont pas des objets du passé, mais sont au contraire plus que jamais d’actualité. De fait, même si la câble série fait le plus souvent place à d’autres moyens de communication inter-processus, l’émulateur de terminal reste l’un des outils essentiels de l’informaticien. On l’utilise non seulement avec le shell de nos ordinateurs personnels, mais aussi pour se connecter avec ssh ou telnet à un programme d’une autre machine du réseau (serveur, routeur, etc.), ou à travers un port série, au moniteur d’un module Arduino.

Remarque : Depuis la version 6.0 de Windows (Vista), il n’y a plus d’émulateur de terminal à usage général préinstallé sur cette plateforme ; l’installation du logiciel libre PuTTY permet de combler cette lacune.