Pourquoi il y a plusieurs shells dans un système de type Unix?

16

Je viens de commencer à apprendre les principes fondamentaux d'Unix et à me demander pourquoi il y a tant de shells dans un système de type Unix. Extrait du livre Programmation avancée dans l'environnement Unix :

Un shell est un interpréteur de ligne de commande qui lit les entrées utilisateur et exécute les commandes. L'entrée utilisateur d'un shell provient normalement du terminal (un shell interactif) ou parfois d'un fichier (appelé script shell).

Et puis le livre énumère un certain nombre de programmes shell comme Bourne shell, Bourne-again shell, Cshell, etc. Ma question est essentiellement pourquoi avons-nous besoin de plusieurs coquilles?

Geek
la source
4
La même raison pour laquelle il existe tant de normes pour diverses autres technologies s'applique. xkcd.com/927
Dan
1
Pour la même raison, vous pouvez avoir des compilateurs / interprètes pour plusieurs langages de programmation (également plusieurs compilateurs pour une langue) ou plusieurs navigateurs Internet.
Mischa Arefiev
6
Votre question est présomptueuse. " Pourquoi avons-nous besoin de plusieurs obus? " Qui vous a dit que nous avions besoin de plusieurs obus? Votre livre dit que nous avons plusieurs obus. Ce n'est pas la même chose.
Rob

Réponses:

15

La plupart des shells utilisés dans les environnements UNIX modernes sont censés être conformes à la spécification sh POSIX. POSIX sh est dérivé du shell Korn d'origine (ksh88), qui est à son tour dérivé du shell Bourne précédent, mais POSIX sh ne spécifie qu'un petit sous-ensemble des fonctionnalités de ksh88 même. Un shell qui n'implémente que l'exigence minimale manque de nombreuses fonctionnalités requises pour écrire tous les scripts sauf les plus triviaux de manière sûre et raisonnable. Par exemple, les variables et tableaux locaux sont des extras non standard.

Par conséquent, la première raison est d'étendre le shell avec des fonctionnalités supplémentaires. Différents obus choisissent de se concentrer sur différentes choses. Par exemple, Zsh se concentre sur les fonctionnalités interactives avancées tandis que ksh93 (le shell korn "original" actuel) se concentre sur les fonctionnalités de programmation et les performances puissantes. Même des shells très minimes comme Dash ajoutent au moins quelques extras non standard comme des variables locales.

Les fonctionnalités supplémentaires sont rarement largement interopérables, voire pas du tout. La plupart des fonctionnalités de ksh88 sont assez bien interopérables telles que la syntaxe de globalisation étendue, mais avec des fonctionnalités non standard, il n'y a aucune garantie, et vous devez vraiment savoir ce que vous faites pour les utiliser de manière portable.

La deuxième raison est l'héritage. Il existe encore beaucoup d'Unix propriétaires qui utilisent d'anciennes implémentations non standard pour leur / bin / sh. Jusqu'à récemment, Solaris utilisait toujours Bourne comme valeur par défaut et a choisi de maintenir le shell Heirloom plutôt que de passer à quelque chose de moderne. Ces systèmes sont généralement livrés avec différents shells sur lesquels vous pouvez basculer, par exemple en changeant votre variable PATH ou en modifiant les shebangs dans des scripts individuels.

Donc, pour résumer. Il existe plusieurs shells, souvent par défaut:

  • Pour des fonctionnalités supplémentaires, en particulier pour gérer les extras non portables.
  • Pour gérer les scripts hérités qui sont souvent non entretenus.
  • taille / performance. Les systèmes embarqués nécessitent souvent de petits shells comme mksh ou busybox sh.
  • Raisons de licence. AT&T ksh était un logiciel propriétaire jusque vers 2000 environ. C'est en grande partie ce qui a donné naissance à tous les clones de type ksh tels que Zsh et Bash.
  • Autres raisons historiques. Bien que peu populaire aujourd'hui, il y a eu des tentatives radicales de refonte de la langue, comme scsh et es. La fonction de substitution de processus de nombreux shells provient à l'origine de rc (avec une syntaxe un peu différente) et de l'expansion d'accolade à partir de csh. Différents obus ont différentes combinaisons de ces fonctionnalités disponibles, généralement avec des différences subtiles ou moins subtiles.
ormaaj
la source
2
Notez que bien qu'il localne soit pas POSIX ou Unix, il est spécifié et requis dans la norme Linux (LSB) et la norme de politique debian . Notez qu'il ess'agit d'un suivi rc.
Stéphane Chazelas
1
Ce qui est maintenant à l' mkshorigine le Bourne Shell du domaine public, qui a également été écrit pour des raisons de licence. (Ces problèmes demeurent - les licences, la portabilité et la taille ont été les trois facteurs qui m'ont aidé à persuader Google d'inclure mksh avec Android.)
mirabilos
19

Parce que les gens ont des besoins différents et qu'il est bon d'avoir des alternatives adaptées à vos besoins dans la situation donnée. Un shell est juste un outil en soi et devrait être remplaçable par tout autre à mon avis. C'est la puissance d'Unix / Linux, contrairement à ce que Microsoft Windows a choisi d'être.

De même ... Pourquoi y a-t-il autant d'éditeurs de texte? Pourquoi les gens développent un nouveau navigateur s'il en existe déjà un? Pourquoi existe-t-il GNOME, KDE, Xfce, LXDE, E17, etc.?

gertvdijk
la source
12
Précisément. On pourrait se demander "pourquoi tant de gestionnaires de fenêtres?" ainsi que. Un natif d'Unix pourrait poser la question inverse: pourquoi un seul CMD.EXE? Pourquoi Windows est-il si rigide et non personnalisable?
Bruce Ediger
1
@BruceEdiger Que voulez-vous dire, juste un cmd.exe? Il existe des alternatives, si vous souhaitez les utiliser. Même Microsoft a lui-même PowerShell comme alternative.
Malcolm
3
Même COMMAND.COMsous DOS était remplaçable. Cependant, vous avez souvent un système très fragile en raison des hypothèses d'autres applications (et d'autres utilisateurs). En conséquence, il existe peu d'alternatives réussies à CMD.EXE. L'un est PowerShell, qui a l'inertie de Microsoft. Un autre exemple est, étrangement, bashdû au soutien décent de la communauté Cygwin, sans parler des gens de MinGW. Quant aux gestionnaires de fenêtres, Windows n'en a eu qu'un à la fois, mais il y en a eu plusieurs au fil du temps au fur et à mesure que l'environnement Windows lui-même évoluait.
RBerteig
+1 pour cette réponse. Je pense que c'est pourquoi nous avons tant de versions UNIX diversifiées: AIX, HP-UX, Solaris, Tru64, IRIX, UnixWare, OS X, Linux, FreeBSD, NetBSD, OpenBSD, ..., vous l'appelez!
tonga
4

Réponse courte

En raison d'un historique de licence étrange, aucune entité n'a développé Unix. Il s'agissait d'un processus communautaire auquel des bénévoles et des sociétés ont participé. Ces entités ne partageaient pas toujours tous leurs outils, des obus séparés se sont donc produits. Au moment où nous avons réalisé à quel point c'était contre-productif, il était trop tard pour unifier tous les obus utilisés. Au lieu de cela, un travail a été fait pour s'assurer que tous ces obus seraient (théoriquement) compatibles entre eux .

La réponse longue est complexe et étroitement liée à l'histoire d'Unix elle-même. Il n'y a aucun moyen qu'il contienne une seule réponse sur cette page, mais cela a été largement (mal) documenté. Vous trouverez des réponses plus détaillées et précises en parcourant le Web et les livres traitant de l'histoire d'Unix.

rahmu
la source
2

Différents obus existent pour les mêmes raisons que différents navigateurs Web: tout le monde a une préférence, et certains obus ont un bagage historique ou un élan. Chacun a des caractéristiques et des particularités différentes.

dotancohen
la source
1

Surtout, l'histoire ...

Bourne a été développé dans le cadre de (la propriété) SysV Unix, tandis que BSD a utilisé csh... Plus tard, bash a été développé comme une alternative open source au Bourne shell (et ses versions améliorées, comme ksh). Un shell de type Bourne a été adopté dans le standard POSIX. ksh est conforme et bash peut être conforme.

Les shells aiment cshet tcshsont beaucoup plus faciles à utiliser de manière interactive que le shell Bourne d'origine (qui manque de complétion de commande, etc.) mais sont horribles pour les scripts ...

Dans certains environnements, tels que les systèmes intégrés basés sur Unix, les fonctionnalités de script, la taille et la vitesse sont plus importantes que les fonctionnalités interactives telles que l'exécution des commandes, et une variante différente des shells a tendance à être utilisée.

Pour les scripts portables, vous devez utiliser une variante Bourne compatible POSIX et éviter les extensions.

Gert van den Berg
la source
3
-1 pour avoir pensé que le monde a commencé à SysV. Le shell Bourne a été publié dans UNIX v7 en 1977, six ans avant la sortie de SysV.
Rob
@Rob, s / 1977/ 1979 /
Stéphane Chazelas
Assez juste ... L'histoire de * nix est assez compliquée ... Voir en.wikipedia.org/wiki/File:Unix_history-simple.svg
Gert van den Berg