Pourquoi Bash est-il partout (dans la plupart sinon toutes les distributions Linux) ?

Histoire (acquise non pas par la recherche mais en passant trop de temps à traîner avec les gens des Bell Labs) :

Au début (si vous considérez que le début est Unix Version 7) était le shell Bourne. Steve Bourne a été le premier à montrer que le shell qui contrôlait l'interaction de l'utilisateur pouvait être un programme utilisateur et non une partie spéciale du système d'exploitation. Une percée historique. Le shell lui-même était relativement propre pour les scripts, mais n'avait pas d'édition de ligne de commande ni de contrôle des tâches. Introduction au shell Unix de Bourne est toujours utile pour les utilisateurs débutants aujourd'hui.

Modifier :J'ai ignoré certaines "préhistoires" de Ken Thompson et John Mashey, également de Multics. Je suis sûr que Bourne était au courant de tout ce travail (il était dans le même laboratoire, 1127, aux Bell Labs), mais la coquille de Bourne était définitive, et le travail antérieur avait peu d'influence, sauf tel qu'interprété par Steve Bourne. Par exemple, bien que Ken ait écrit plus tard le compilateur Plan 9 C et ait été très influent sur Plan 9, mais l'article de Tom Duff sur le shell Plan 9 (rc) ne mentionne que le shell de Bourne, pas celui de Thompson.
Le shell n'est qu'un programme utilisateur, donc n'importe qui peut en écrire un. Alors que la version 7 d'Unix était en cours de création dans le New Jersey, Berkeley Unix était en cours de création en Californie. Bill Joy à Berkeley a écrit csh , la coque C. Joy a ajouté le contrôle et l'historique des tâches, puis l'édition de la ligne de commande, mais n'était pas au courant du travail de Bourne et a donc basé son langage sur le shell Thompson (que je considérais comme "préhistorique" dans le point précédent). La communauté Unix aimait le contrôle des tâches, mais elle aimait aussi le langage de Bourne. Pour une polémique pas particulièrement bonne contre le langage csh, voir Csh Programming Considered Harmful. Pendant un certain temps, de nombreuses personnes ont utilisé csh de manière interactive pour ses fonctionnalités de contrôle des tâches et d'historique, mais a utilisé le sh de Bourne pour écrire des scripts. Cette situation n'était pas idéale.

Modifier :Merci à DigitalRoss de m'avoir éclairci sur la chronologie de csh . Depuis que j'ai reçu mon éducation de personnes qui se réfèrent à BSD comme "l'hérésie de Berkeley", j'étais assez à court de faits là-bas.
Dave Korn de Bell Labs a fait une brillante réingénierie du shell Bourne pour produire le shell Korn (ksh). Il était entièrement rétrocompatible avec le shell Bourne sh mais a fourni une cargaison d'améliorations inestimables. ksh est devenu la base d'une norme POSIX et a été livré en standard avec le logiciel Sun. (Ceci malgré le fait que Bill Joy a quitté Berkeley pour aider à fonder Sun et était l'un de leurs principaux développeurs de logiciels.)
Bell Labs et AT&T échouent bêtement à faire ksh Open source. ksh88 est largement utilisé, mais avoir des sources n'est pas légal. Certaines personnes deviennent tellement dépendantes qu'elles deviennent des cybercriminels.

Modifier :Était-ce vraiment si stupide ? Difficile à savoir. Berkeley donnait déjà Unix, et d'autres sociétés allaient bientôt suivre, mais c'était encore l'époque où les maîtres d'entreprise croyaient qu'il fallait faire payer Unix. Mais les résultats :AT&T Unix est mort, après avoir été vendu à diverses parties un certain nombre de fois. BSD et ses dérivés sont bel et bien vivants, mais ces choses parvenues appelées "Linux" et "GNU" ont une part énorme de l'esprit qui appartenait autrefois aux Bell Labs.
La Free Software Foundation fait une "salle blanche", à partir de zéro, implémente un shell POSIX, en prenant toutes les idées de Dave Korn comme alors actuelles, plus dans le style FSF habituel en ajoutant de nouvelles fonctionnalités qui leur sont propres, telles que la complétion programmable. Ils l'appellent le shell "Bourne again", ou bash .
Au milieu des années 1990, AT&T open-sources ksh93 , mais il est alors trop tard pour une adoption généralisée. L'accord de licence est étrangement non standard. bash et ksh divergent, et ksh n'atteint jamais une part de marché à la hauteur de sa place dans l'histoire.

Leçons :

Le premier produit adéquat à commercialiser gagne (sh).
Les gens aiment les nouvelles fonctionnalités (contrôle des tâches, exécution des commandes), mais ils les aiment encore plus lorsque leurs anciens scripts continuent de fonctionner.
Modifier :Les professeurs d'ingénierie devraient laisser l'histoire aux historiens des sciences :-)

Bash a deux choses complètement différentes à faire.

C'est une belle coquille. C'est peut-être l'un des 2 shells (l'autre est zsh) qui intègre certains des cools csh fonctionnalités telles que ! substitution d'historique dans la syntaxe posix. Il a beaucoup d'extensions, y compris des tableaux.
C'est le shell FSF/GNU. Dans le monde open source, cela lui donne une sorte de cachet.

Je dois également ajouter que ce n'est pas toujours la valeur par défaut. ash est souvent utilisé comme /bin/sh de sorte que tant que bash peut être le shell interactif, ash est le shell "il suffit d'exécuter le fichier de commandes". C'est parce que ash est plus petit et plus rapide, et contient les fonctionnalités posix, c'est donc un sous-ensemble approprié. Utilisation de ash en tant que shell interactif est parfois problématique. Sur, disons, NetBSD, cela fonctionne bien, car il est construit avec toutes les fonctionnalités. C'est un peu leur seule coquille alors que bash est un package externe. Mais sous Linux ash est généralement considéré comme non interactif, donc ils le compilent sans l'historique et sans l'édition de ligne (importante) sur la théorie qu'il est juste utilisé pour exécuter ces énormes gnu configure scripts.

Conte de deux coquillages

La véritable histoire du shell

MISE À JOUR : Il existe un historique inexact de la copie du shell d'un endroit à l'autre sur le Web, et les gens le croient à juste titre. Je vais essayer de donner une version précise et de fournir quelques liens pour l'étayer ici.

Le premier shell n'était certainement pas le shell Bourne mais a été écrit par Ken Thompson lui-même et distribué en V6, qui est la version envoyée par AT&T à diverses universités et laboratoires gouvernementaux. C'est ce qui a mis Unix sur la carte. Il avait toutes les bases, <, >, >>, |, & , mais il n'y avait qu'un simple goto syntaxe de contrôle via un programme externe qui a cherché sur l'entrée standard. Il n'y avait alors pas de scripts shell complexes. Les shells ultérieurs ouvriraient l'entrée de commande sur un fd séparé. Cela peut sembler simple aujourd'hui, mais dans le film d'horreur qu'était l'informatique des années 1970, c'était la meilleure chose au monde. Croyez-le ou non, cet ancien coquillage a aujourd'hui son propre flux Twitter et, bien sûr, une page d'accueil.
Le deuxième obus était csh , écrit (comme vi ) par Bill Joy chez UCB. C'était avant GNU readline et NetBSD editline, il devait donc sembler parfaitement raisonnable de faire l'histoire avec le ! syntaxe. Csh a ajouté la plupart des fonctionnalités du shell d'aujourd'hui, mais avec la syntaxe csh. csh n'a modifié aucune syntaxe , gratuitement ou autrement. Il était en fait rétrocompatible avec le shell Thompson et incluait à l'origine le code source TS.
Le troisième shell était le shell Bourne, avec une syntaxe différente. Unix était développé en parallèle chez UCB et AT&T. Ce shell avait un répartiteur de mémoire étrange (je pense qu'il utilisait simplement plus de mémoire, piégeait SIGSEGV, faisait un nouveau brk(2), puis réessayait) qui rendait difficile l'exécution sur de nouveaux ports Unix, donc osh et csh resté populaire pendant un certain temps. Il n'y avait pas d'Internet et il était sous licence SW, donc dans cet environnement, il est possible que Stephen Bourne ne connaisse pas le shell de Joy et certainement Joy ne connaissait pas Bourne. Il est possible que les deux shells se soient rencontrés pour la première fois lorsque UCB a obtenu un VAX et une pré-version du désormais oublié Unix/32V. Je me souviens que Bill se plaignait de l'allocation de mémoire. Notez que les deux shells étaient rétrocompatibles avec le shell V6 , ils ont simplement étendu la syntaxe dans différentes directions.
Maintenant, il y avait vraiment plusieurs shells incompatibles, auxquels AT&T a ajouté le ksh compatible Bourne . Finalement, csh avait un code source semi-disponible, mais il était lié à un procès entre AT&T et l'Université de Californie. Pourtant, c'était l'époque glorieuse de BSD Unix, car les entreprises sophistiquées qui pouvaient se permettre les 50 000 $ achetaient la licence AT&T mais installaient les distributions BSD 4.x, et les universités l'obtenaient gratuitement.
Dans cette situation comportant de nombreux problèmes juridiques et techniques, diverses mises en œuvre indépendantes ont été entreprises. Au moins autant sont allés avec le csh syntaxe identique à celle de la syntaxe du shell Bourne, et certains ont fusionné les deux. Vous avez eu au moins tcsh , zsh , bash , et ash . La syntaxe Bourne était "officielle", faisant partie des versions d'AT&T, mais à cette époque, BSD était assez important, et Sun, initialement BSD, distribuait une bonne partie du logiciel Unix que le monde rencontrait.
En partie à cause du procès de l'USL, la FSF et Linux avaient un champ libre. Pendant ce temps, AT&T avait réussi à se battre avec l'une des rares entités sur terre plus grande qu'eux (l'État de Californie) et à la fin, ils n'ont pas gagné le procès, et donc finalement la distribution BSD était sur une base juridique ferme. pied. Mais à ce moment-là, Linux et bash étaient partout, et donc aujourd'hui, BSD est une niche.
Enfin, bash est une bonne coquille (bien qu'apparemment désavouée en privé par son auteur original) et elle mérite pleinement le mérite de son propre succès. csh aurait été éclipsé par tcsh et zsh même si ash, bash et ksh n'avaient pas gagné la guerre de syntaxe.

Pour ajouter à ce que @DigitalRoss a dit

Bash est un remplacement complet du sur-ensemble pour posix-sh, même au point s'il est appelé comme /bin/sh émulera entièrement posix-sh. Posix-sh était le "standard" des systèmes Unix commerciaux en tant que shell à dénominateur commun. Donc, quelque chose qui commence là et qui s'appuie là-dessus commence par beaucoup.