Bourne shell (sh)

Découvrons ensemble brièvement l’ancêtre des shells utilisés sur les OS Unix: le Bourne shell. Sa première version est apparue en 1977, sous la version 7 d’Unix. Il a été mis en place pour améliorer, voire remplacer, le Thompson shell, créé six ans plus tôt. En effet, les limites du Thompson shell étaient considérables: absence des variables, aucun contrôle des flux, interactivité limitée avec l’utilisateur, etc. L’enjeu était donc de concevoir un langage de script entièrement programmable, interactif, et qui pourrait servir d’interface aux utilisateurs.

J’en ai déjà entendu parlé je crois. Non?

Aujourd’hui, lorsque nous demandons à notre ordinateur du département TC de lancer un script (sous linux), nous avons à notre disposition l’environnement console bash. L‘origine de ce shell, c’est le Bourne shell, également connu sous l’abréviation sh. Bash (Bourne Again SHell) n’est donc qu’une des versions améliorées de sh.

Malgré son ancienneté, Bourne shell reste quand même l’interface système la plus répandue dans l’univers Unix puisqu’elle y est directement installée.

Et comment ça marche?

Le langage utilisé s’appelle un script shell. Dans un fichier d’extension .sh, le programme va contenir les étapes que la machine devra exécuter. Tout script aura comme première ligne, la description du Shell à lancer. Dans notre cas, il faudra préciser #!/bin/sh si l’on veut que le script s’exécute nécessairement via le Bourne Shell.

On aura donc :

1. Création du script mon_script.sh

Ouvrons un terminal. Créons le script suivant grâce à l’éditeur vim:

Le programme suivant salue l’utilisateur, lui demande son nom, et lui souhaite la bienvenue.

2. Exécution du script mon_script.sh avec Bourne shell

De nouveau dans le terminal, la commande sh mon_script.sh permet directement l’exécution du script.

L’invocation du Bourne shell par sh [nom_du_script.sh] permet de créer un shell différent du shell courant, sans qu’il n’y ait obligation d’attribuer des droits d’exécution. A la fin du programme, le Bourne shell est automatiquement fermé et on revient au shell précédemment activé.

2bis. Attribution de droits et exécution

Une autre alternative serait de ne pas passer par le Bourne shell et d’utiliser l’interface déjà activée (sans doute une version améliorée de sh). Il faut alors attribuer des droits au script avant de le lancer dans le shell courant:

chmod u+x mon_script.sh

./mon_script.sh

Quels avantages à utiliser le Bourne shell?

1. La compatibilité. Si votre OS Unix utilise bash, csh, ou tout autre shell, votre script shell .sh restera exécutable puisque Bourne shell y est installé par défaut.
2. L’autorisation automatique. Lorsque l’on invoque le Bourne shell pour exécuter un script .sh, nous avions vu qu’il n’est pas nécessaire de donner une autorisation spécifique à ce dernier. Avantage certes minime, mais une permission pas toujours accordée sous d’autres shells.
3. La communication mutuelle entre processus. Grâce à la création des variables d’environnement, l’utilisateur n’est plus obligé de préciser dans sa commande le contexte dans lequel elle se lance (c’était plutôt encombrant…). Par exemple, la variable d’environnement PATH nous permet désormais de configurer une bonne fois pour toutes la liste de répertoires à utiliser à l’exécution d’une commande.
4. Le contrôle des flux. Le problème avec Thompson Shell était qu’il ne pouvait ni effectuer de boucles, ni vérifier des conditions. Avec le Bourne Shell, cela a été résolu avec l’arrivée de for, while, if et test.

Des limites au Bourne shell?

1. Des fonctionnalités insuffisantes. A l’époque de son apparition, il n’y avait ni historique, ni redirections, ni modifications de commande… Bref, c’était assez limité pour l’utilisateur, et c’est d’ailleurs la raison pour laquelle des versions améliorées sont rapidement apparues.
2. Des performances médiocres. Si par exemple vous aimeriez optimiser votre algorithme de tri, les scripts shells seront certainement le dernier recours. Aussi, le traitement de fichiers volumineux est une des lacunes remarquables du Bourne shell.
3. Une forte exigence syntaxique. Comme tout langage de programmation, des contraintes syntaxiques ont été mis en place. Par exemple, un simple ajout d’espace entre deux mots-clés engendre une erreur de syntaxe, qui par ailleurs n’est pas toujours facile à repérer.

Et si je veux essayer de comprendre les shells et leur script?

Malgré toutes les limites de Bourne shell, il est toutefois essentiel de retenir qu’il s’agit DU shell historique et standardisé, sans lequel Unix n’aurait pas autant de succès. Pour assouvir sa curiosité pour les langages de programmation, notamment ceux utilisés dans l’administration système, le mieux serait de commencer par un tutoriel classique sur les scripts shell, comme celui proposé par openclassrooms.