Petite histoire du Bourne Shell

Posté par (page perso) . Édité par Benoît Sibaud, palm123 et tankey. Modéré par tankey. Licence CC by-sa
90
20
mar.
2015
Doc

Nos systèmes d'exploitations sont forgés par l'histoire. Ils se sont formés par stratifications d'inventions accumulées. Les idées de Ken Thompson, Steve Bourne, et Bill Joy - pour ne citer que les personnes dont il est question dans cette dépêche - sont fossilisées dans les sources des logiciels que nous utilisons aujourd'hui. Parce qu'un rappel historique nous permet de comprendre les raisons du fonctionnement actuel d'un logiciel, cette dépêche présente rapidement l'histoire du shell de Bourne.

Sommaire

Thompson Shell

Simple interpréteur

Le shell orignal d'UNIX a été créé par Ken Thompson. D'abord pensé comme simple interpréteur de commande, il n'avait aucune fonction de programmation : ni contrôle de flux (tels if et while), ni variables, ni fonctions.

Tubes

Il permettait néanmoins d'enchaîner les commandes par l'utilisation des tuyaux. La notion de filtre et sa symbolisation ont en effet été mises au point en 1972. Le Thompson Shell utilisait le même symbole (>) pour enchaîner les commandes que pour déporter la sortie vers un fichier :

    com1 > com2 > com3 > outfile

Cette syntaxe était peu pratique, car il fallait mettre entre guillemets les commandes contenant des arguments, et parce que le shell ne pouvait distinguer entre un programme et un fichier. Enfin, pour écrire sur la sortie standard, il fallait le spécifier explicitement :

    com1 > com2 > com3 >

C'est en 1973, pour la quatrième édition d'UNIX, que la syntaxe des tubes est repensée, et c'est le symbole ^ qui est utilisé pour les représenter.

Scripts

Le Thompson Shell permettait d'exécuter les commandes inscrites dans un fichier, et donc de créer des scripts rudimentaires.

Les premières commandes de contrôle de flux utilisables par le Thompson shell étaient en fait des commandes extérieures au shell : /bin/if et /bin/goto. C'est au milieu des années 70 que quelques commandes sont ajoutées au Thompson Shell pour en faire un langage de programmation. La possibilité d'utiliser des variables est aussi ajoutée, de sorte que le Thompson Shell devient véritablement programmable. Cette nouvelle version du Thompson Shell est parfois nommée PWB (Programmer's WorkBench) shell, ou Mashey Shell.

On peut trouver quelques exemples de scripts pour une version tardive du Thompson Shell.

Bourne Shell

Steve Bourne a commencé à travailler sur son shell vers 1975 ou 1976, mais ce n'est qu'en 1979 qu'il est officiellement introduit dans la septième édition d'UNIX. Les premières versions du Bourne Shell sont écrites dans une variante du C ressemblant à l'Algol (Algol like variant of C). En 1982, le bourne shell est ré-écrit en C Kernighan et Ritchie (le C dans le style de leur livre de 1978).

Chaînes de caractères et variables

Dans une longue interview de ComputerWorld, Bourne explique que pour simplifier la vie des usagers d'UNIX il fallait commencer par simplifier l'usage des chaînes de caractères. Avant le Bourne Shell, les variables sont des noms, et les chaînes de caractères sont repérées par leurs guillemets. Bourne propose l'inverse : il suffit de taper une chaîne de caractères pour qu'elle soit reconnue comme telle, et tout ce qui n'est pas une chaîne de caractères doit être identifié. Ainsi, l'usage du $ a été proposé pour reconnaître les variables. La possibilité d'exporter les variables dans l'environnement - et donc de créer des variables d'environnement - a été introduite sur les systèmes UNIX avec la septième version du Bourne Shell. Enfin, ce n'est qu'à partir de 1981 que le caractère # peut être utilisé pour les commentaires.

Filtres

Si les shells en usage avant celui de Bourne permettaient d'utiliser les filtres, ils ne permettaient pas de créer des scripts qui fonctionnent eux-mêmes comme filtres, car l'entrée standard était le script lui-même. Cette limitation est levée par le Bourne Shell.

Dans le même esprit il introduit la substitution de commande : 'commande' permet d'utiliser le résultat de commande comme argument d'un script. C'est aussi avec le Bourne Shell que sont introduites les redirections >&, <&, <&- et >&. Il introduit enfin une syntaxe pour indiquer qu'un document suit (here document) :

    <<-EOF
            Ceci est un document
    EOF

Cette ergonomie du Bourne Shell a été conservée par ses épigones jusqu'à aujourd'hui. Héritier du Thompson Shell, le traditionnel Bourne Shell se reconnaît néanmoins facilement au fait que le symbole ^ peut être utilisé comme remplacement du symbole | pour créer des tuyaux.

Performances

À la fin des années 70, tant le Bourne Shell que le Thompson Shell étaient présents et utilisés sur UNIX. Le Thompson Shell avait alors incorporé les idées de Bourne. Comme ils n'étaient pas compatibles entre-eux, la question s'est posée de savoir lequel des deux devait être le shell standard d'UNIX. C'est finalement le Bourne Shell qui a été choisi.

Si le Bourne Shell facilitait la création de scripts, cet avantage n'était que mineur suite aux évolutions du Thompson Shell. C'est plutôt les performances du shell de Bourne qui ont convaincu les utilisateurs d'UNIX. De fait, sur l'année de travail qu'a représenté l'écriture du Bourne Shell, six mois ont été consacrés à l'amélioration de ses performances.

L'édition de commandes

Le Bourne Shell, ne proposait pas d'historique, ni n'offrait la possibilité d'éditer une commande commencée. Ces fonctionnalités ont été introduites avec le C shell de Bill Joy, qui travaillait alors à l'université de Berkeley. La possibilité d'éditer une commande en mode vi ou emacs a ensuite été portée sur le Bourne Shell.

Évolutions

Bourne cesse d'améliorer son Shell en 1983 après y avoir introduit les fonctions. Dans l'interview de ComputerWorld, il explique que :

« Aucun langage ne peut résoudre tous les problèmes du monde de la programmation, ainsi, soit il en reste au point où vous le conservez simple et raisonnablement élégant, soit vous continuez sans cesse à ajouter des trucs. […] J'ai donc décidé que le shell avait atteint ses limites à l'intérieur des contraintes structurelles qui sont les siennes. »

« Any one language cannot solve all the problems in the programming world and so it gets to the point where you either keep it simple and reasonably elegant, or you keep adding stuff. [….] So I decided that the shell had reached its limits within the design constraints that it originally had. »

Le Bourne shell a donc peu évolué depuis, il a néanmoins été adapté aux normes POSIX. Comme ce shell a inspiré ceux d'aujourd'hui, il est possible qu'il puisse toujours exécuter certains scripts créés pour d'autres shell.

Heirloom Bourne Shell

Pour le Projet Heirloom, Gunnar Ritter a converti le code source du bourne shell à la norme ANSI du C. Cette version ne supporte pas la norme POSIX-2, car cela allait à l'encontre de certaines caractéristiques originales du shell. Cultivant une certaine nostalgie, Gunnar Ritter trouve des raisons d'utiliser le shell de Bourne :

« Bien sur, il lui manque quelques caractéristiques plaisantes telles que l'historique des commandes, la complétion de la ligne de commande, etc. Mais travailler avec ces particularités tend à distraire l'attention de l'utilisateur. Après une phase de familiarisation, l'utilisation du Bourne Shell peut conduire à un style de travail plus tempéré et concentré. Essayez-le. Sérieusement. »

« Of course, it lacks fancy features such as a command history, command line completion, etc. But working with these features tends to distract the user's attention. After a familiarization phase, use of the Bourne shell can lead to a more even-tempered, concentrated working style. Give it a try. Seriously. »

  • # Ouh lal la !! Honte à toi :

    Posté par . Évalué à -2. Dernière modification le 20/03/15 à 22:33.

    Le shell orignal d'UNIX a été créé par Ken Thomson. BIIIIIIP : C'est Ken Thompson l'un des 3 papas d'Unix !!! Honte à toi !!!

    C'est vraiment une faute à ne pas faire dans ce genre d'article, et sur un site comme Linuxfr, surtout lorsque le lien donné dans l'article contient le bon nom !!! Et ce n'est même pas une faute de frappe, j'ai vu la faute 2 fois (en fait elle est partout, plein de fois) : Thompson shell.

    • [^] # Re: Ouh lal la !! Honte à toi :

      Posté par (page perso) . Évalué à 10.

      Il a passé la modération… L'erreur est humaine ;-)

      Personnellement, je félicite l'auteur pour son article.

    • [^] # Re: Ouh lal la !! Honte à toi :

      Posté par (page perso) . Évalué à 7. Dernière modification le 21/03/15 à 09:27.

      Ah, tiens, effectivement, il y a un « p » à Thompson. Merci, je ferai attention dorénavant.

      Pardon aux familles, etc…

      Est-ce qu'un modérateur peut corriger cette erreur ?

      • [^] # Re: Ouh lal la !! Honte à toi :

        Posté par . Évalué à 7.

        Ne prends pas mal on commentaire, je te chambre, c'est tout. Ce n'est pas pou être méchant. Mais comme j'ai pas mis de smiley, ça peut prêter à confusion. Comme dit par ailleurs, l'article est très bien rédigé par ailleurs.

        • [^] # Re: Ouh lal la !! Honte à toi :

          Posté par (page perso) . Évalué à 3.

          Je ne pas mal pris ton commentaire, je ne l'ai même pas moinssé. Connaissant ta prose, j'ai perçu la taquinerie. Du reste tu as raison, honte à moi.

          Quant à la qualité de la dépêche, j'ai un avis mitigé sur la question: J'ai retrouvé des notes que j'avais prises il y a un an ou deux pour écrire une dépêche finalement abandonnée. Considérant qu'il valait tout de même mieux publier ce travail inabouti que ne rien en faire, je l'ai rapidement mis en forme.

    • [^] # Re: Ouh lal la !! Honte à toi :

      Posté par (page perso) . Évalué à 6.

      Corrigé, merci.

  • # Le français, ce bon vieux langage qui ne devrait pas compiler vu les fautes

    Posté par (page perso) . Évalué à -10.

    On ne dit pas « continuer à faire quelque chose » mais « continuer de faire quelque chose », c’est comme dire « la voiture à bidule ».

    « Aucun langage ne peut résoudre tous les problèmes du monde de la programmation, ainsi, il en reste au point où vous le conservez simple et raisonnablement élégant, ou alors vous continuez sans cesse à ajouter des trucs. […] J'ai donc décidé que le shell avait atteint ses limites à l'intérieur des contraintes structurelles qui sont les siennes. »

    « Any one language cannot solve all the problems in the programming world and so it gets to the point where you either keep it simple and reasonably elegant, or you keep adding stuff. [….] So I decided that the shell had reached its limits within the design constraints that it originally had. »

  • # Fôte

    Posté par . Évalué à 3. Dernière modification le 21/03/15 à 08:46.

    Seuls ceux qui ne font rien ne font pas d'erreurs ! Quant à la manière de les relever, tout le monde est juge …

    Guillaume

    • [^] # Re: Fôte

      Posté par . Évalué à 9.

      Ceux qui ne font rien font au moins une erreur : ne rien faire.

      Cela montre que tout le monde fait des erreurs, même en ne faisant rien.

  • #

    Posté par . Évalué à 5. Dernière modification le 21/03/15 à 13:34.

    J'ai enfin un poil plus d'explication sur pourquoi parfois par le passé quand on tapait sur la touche marquée "|" on voyait "^" à l'écran, ou inversement, par exemple sur le CP/M des vieux Amstrad de mémoire.

    Par contre pour lancer le CP/M ou certains jeux depuis l’interpréteur Basic on voyait un obscur "ù" s'afficher :) comprenne qui pourra, sûrement une obscure question de keymap.

    • [^] # Re: ↑

      Posté par . Évalué à 1.

      Par contre pour lancer le CP/M ou certains jeux depuis l’interpréteur Basic on voyait un obscur "ù" s'afficher :) comprenne qui pourra, sûrement une obscure question de keymap.

      ça semble être une question de mapping car sur les clavier qwerty tu pouvais taper |cpm

  • # Merci pour cette petite histoire du shell

    Posté par . Évalué à 5.

    Je trouve bien cool ce petit retour d'histoire sur l'origine du shell, et j'en félicite l'auteur. Je n'ai pas autant de connaissance sur l'histoire informatique que je le pensais.

    Merci

  • # Mot manquant

    Posté par (page perso) . Évalué à 2.

    En 1982, le bourne shell est ré-écrit en C Kernighan et Ritchie.

    En 1982, le bourne shell est ré-écrit en C par Kernighan et Ritchie ?

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Mot manquant

      Posté par (page perso) . Évalué à 3.

      Corrigé, merci.

      • [^] # Re: Mot manquant

        Posté par (page perso) . Évalué à 3.

        Merci, mais si « C Kernighan et Ritchie » n'est pas une expression connue, il faudrait mieux écrire « en C K&R » ou « en C à la façon de Kernighan et Ritchie ». Mais certainement pas « réécrit en C par », comme l'explique mon commentaire ci-dessous.

        Encore merci.

    • [^] # Re: Mot manquant

      Posté par (page perso) . Évalué à 4.

      Il n'y a pas de mot manquant, c'est une traduction littérale de l'expression « K&R C ».

      En fait, avant que ne soit publiée en 1989 la norme ANSI du C, le livre de Kernighan et Ritchie (The C Programming Language, de 1978) a servi de spécification informelle, ou de plus petit dénominateur commun, des diverses implémentations du langage.

      • [^] # Re: Mot manquant

        Posté par (page perso) . Évalué à 0.

        C'est exacte. Cependant cette expression est selon moi trompeuse (comme on a pu le voir) et sans véritable intérêt en réalité.
        Je veux dire, il est rare dans ce genre de récits de parler de réécriture dans un langage donné dans une version particulière, on se contente de préciser le langage de destination sans précision. J'ai rarement vu des expressions telles que "réécrit en C++99", dire que c'est du C++ est suffisant (l'époque pouvant aider éventuellement à déterminer la version).

        • [^] # Re: Mot manquant

          Posté par (page perso) . Évalué à 5.

          Ça pourrait arriver sur des choses un peu exotiques comme les digraphes/trigraphes par exemple, cf http://en.wikipedia.org/wiki/Digraphs_and_trigraphs et des clarifications apportées en C99 : ainsi un code qui utilise la nouvelle forme (inexistante en C pré-99) plutôt que l'ancienne (existant encore avec C99) pourrait être dit « écrit en C99 ».

          C'est probablement moins marqué néanmoins qu'en Java par exemple, qui déconseille (« deprecated ») des parties d'API. On peut ainsi supposer qu'un code dit « écrit en Java 8 » (notamment) ne comporterait plus de classes ou méthodes déconseillées des versions 1.0, 1.1, 1.2, 1.3, 1.4, 5, 6 et 7.

  • # Formulation étrange

    Posté par . Évalué à 2.

    Aucun langage ne peut résoudre tous les problèmes du monde de la programmation, ainsi, il en reste au point où vous le conservez simple et raisonnablement élégant, ou alors vous continuez sans cesse à ajouter des trucs.

    J'ai eu du mal à comprendre cette phrase : j'ai du avoir recours à la version anglaise pour comprendre. On pourrait dire :

    Aucun langage ne peut résoudre tous les problèmes du monde de la programmation, ainsi, soit il en reste au point où vous le conservez simple et raisonnablement élégant, soit vous continuez sans cesse à ajouter des trucs.

    En tous cas très bon article, merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.