Bash est utilisé par défaut dans toutes les distributions Linux que j'ai essayées, par rapport à des alternatives telles que Z shell (zsh). Y a-t-il une raison technique ou historique à cela?

Histoire (acquise non par la recherche, mais par trop de temps passé avec les gens des Bell Labs):

1. Au début (si vous considérez le début comme étant 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 ne disposait d'aucune édition en ligne de commande ni de contrôle de travail. L' introduction de Bourne au shell Unix est toujours utile pour les utilisateurs débutants aujourd'hui.

   Edit : J'ai ignoré certaines "préhistoire" 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 précédent avait peu d'influence si ce n'était interprété par Steve Bourne. Par exemple, bien que Ken ait écrit plus tard le compilateur Plan 9 C et ait exercé une grande influence sur Plan 9, le papier de Tom Duff sur le shell Plan 9 ne mentionne que le shell Bourne, pas celui de Thompson.

2. Le shell est juste un programme utilisateur, donc tout le monde peut en écrire un. Alors que la version 7 de Unix était créée dans le New Jersey, Berkeley Unix était créée en Californie. Bill Joy à Berkeley a écrit csh, le C shell. Joy a ajouté le contrôle des tâches et l'historique, puis l'édition en ligne de commande, mais n'était pas au courant du travail de Bourne et a donc basé son langage sur le shell Thompson (ce que je considérais comme "préhistorique" dans la puce précédente). La communauté Unix aimait le contrôle du travail, mais elle aimait aussi le langage de Bourne. Pour une polémique pas particulièrement bonne contre le langage csh, voir Programmation de Csh considérée comme nuisible . À une certaine époque, de nombreuses personnes utilisaient de manière cshinteractive pour ses fonctions de contrôle des tâches et d'historique, mais utilisaient celles de Bourne shpour écrire des scripts. Cette situation était moins qu'idéale.

   Edit : Merci à DigitalRoss pour m'avoir éclairé sur la chronologie de csh. Depuis que j'ai reçu mon éducation de personnes qualifiant BSD d '"hérésie de Berkeley", il me manquait beaucoup de faits.

3. Dave Korn de Bell Labs a procédé à une brillante réingénierie du shell Bourne afin de produire le shell Korn (ksh). Il était totalement compatible avec Bourne Shell, shmais il apportait de nombreuses améliorations inestimables. kshest devenu la base d’un standard 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 qu’il était l’un de leurs principaux développeurs de logiciels.)

4. Bell Labs et AT & T échouent stupidement à créer de l’ kshopen source. ksh88est largement utilisé, mais avoir des sources n’est pas légal. Certaines personnes deviennent tellement dépendantes qu'elles deviennent des criminels numériques.

   Edit : Était-ce vraiment si stupide? Difficile de savoir. Berkeley cédait déjà Unix, et d’autres sociétés allaient bientôt suivre, mais c’était encore l’époque où les Corporate Masters croyaient qu’il fallait faire payer Unix. Mais le résultat: AT & T Unix est mort, après avoir été vendu à différentes parties à plusieurs reprises. BSD et ses dérivés sont bien vivants, mais ces choses récentes telles que "Linux" et "GNU" ont une fraction énorme de mentalités partagées qui appartenait autrefois aux Bell Labs.

5. La Free Software Foundation réalise une "salle blanche", à partir de rien, à partir d'un shell POSIX, reprenant toutes les idées de Dave Korn à jour, et ajoute, dans le style habituel de la FSF, de nouvelles fonctionnalités, telles que l'achèvement programmable. Ils appellent cela le "Bourne again" shell, ou bash.

6. Au milieu des années 1990, AT & T a ouvert des sources ksh93, mais il est trop tard pour une adoption généralisée. L'accord de licence est étrangement non standard. bashet kshdiverger, et kshne réalise part de marché en rapport avec sa place dans l' histoire.

Cours:

• Le premier produit adéquat sur le marché 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.

• Edit : Les professeurs d’ingénierie devraient laisser l’histoire aux historiens des sciences :-)

Bash a deux choses complètement différentes.

1. C'est une belle coquille. Il s’agit de l’un des deux types de shell (l’autre est zsh) qui intègre certaines des cshfonctionnalités intéressantes telles que la !substitution d’historique dans la syntaxe posix. Il a beaucoup d'extensions, y compris des tableaux.

2. C'est le shell de la FSF / GNU. Dans le monde open source, cela lui donne une sorte de cachet.

Je devrais aussi ajouter que ce n'est pas toujours la valeur par défaut. ashest souvent utilisé en tant que / bin / sh, ce qui fait que bashle shell interactif ashest le shell "exécutez simplement le fichier de commande". En effet, il ashest plus petit et plus rapide et contient les fonctionnalités posix. Il s’agit donc d’un sous-ensemble approprié. L'utilisation en ashtant que shell interactif est parfois problématique. Par exemple, sur NetBSD, cela fonctionne bien, car il est construit avec toutes les fonctionnalités. C'est un peu leur shell alors qu'il bashs'agit d'un paquet externe. Mais sous Linux ashétant généralement considéré comme non interactif, ils le compilent sans l'historique et sans l'édition de ligne (importante) sur la théorie selon laquelle il est simplement utilisé pour exécuter ces énormes gnu configurescripts.

Conte de deux coquilles

La vraie histoire de la coquille

MISE À JOUR: Il y a une histoire inexacte du shell en cours de copie d'un endroit à un autre sur le Web, et les gens le croient de manière compréhensible. Je vais essayer de donner une version précise et de fournir quelques liens pour le justifier ici.

1. Le premier shell n'était certainement pas le shell Bourne mais avait é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 avait juste une gotosyntaxe de contrôle simple via un programme externe qui cherchait sur une entrée standard. Il n'y avait alors aucun script shell complexe. 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 des années 1970, l'informatique était la meilleure chose au monde. Croyez-le ou non, cet ancien shell possède aujourd'hui son propre flux Twitter et, bien sûr, une page d'accueil .
2. La deuxième enveloppe a été csh, écrit (comme cela a été vi) par Bill Joy à UCB. C'était avant GNU readline et NetBSD editline, il devait donc sembler parfaitement raisonnable de faire l'historique avec la !syntaxe. Csh a ajouté la plupart des fonctionnalités actuelles du shell, mais avec la syntaxe csh. csh n'a pas changé la syntaxe , gratuitement ou autrement. En réalité, il était rétrocompatible avec le shell Thompson et incluait à l'origine le code source TS.
3. Le troisième shell était le shell Bourne, avec une syntaxe différente. Unix a été développé en parallèle chez UCB et AT & T. Ce shell avait un allocateur mémoire étrange (je pense qu’il utilisait plus de mémoire, capturait SIGSEGV, faisait un nouveau brk (2), puis essayait à nouveau) qui rendait difficile l’exécution de nouveaux ports Unix, oshet cshrestait populaire pendant un certain temps. . Il n'y avait pas d'internet et le logiciel était sous licence SW. Dans cet environnement, il est donc possible que Stephen Bourne ne connaisse pas le shell de Joy et que Joy ne soit certainement pas au courant de Bourne. Il est possible que les deux obus se soient rencontrés pour la première fois lorsque UCB a reçu un VAX et une version préliminaire du Unix / 32V maintenant oublié . Je me souviens de Bill qui se plaignait de l'allocation de mémoire. Notez que les deux coques étaient rétrocompatibles avec le shell V6, ils ont simplement étendu la syntaxe dans différentes directions.
4. Maintenant, il y avait vraiment plusieurs coques incompatibles, auxquelles AT & T a ajouté le compatible Bourne ksh. Finalement, le cshcode source était semi-disponible, mais il faisait l'objet d'un procès entre AT & T et l'Université de Californie . Pourtant, c’était le jour de gloire de BSD Unix, car les entreprises sophistiquées qui pouvaient se permettre des frais de 50 000 dollars achèteraient la licence AT & T mais installeraient les distributions BSD 4.x, et les universités l’obtiendraient gratuitement.
5. Dans cette situation de nombreux problèmes juridiques et techniques, différentes mises en œuvre indépendantes ont été entreprises. Au moins autant sont allés avec la cshsyntaxe que la syntaxe du shell Bourne, et certains ont fusionné les deux. Vous avez eu au moins tcsh, zsh, bashet ash. La syntaxe Bourne était «officielle», elle faisait partie des versions d’AT & T, mais à l’époque, BSD était assez important et Sun, initialement BSD, distribuait une bonne partie des logiciels Unix rencontrés dans le monde.
6. En partie à cause du procès USL, la FSF et Linux avaient un champ ouvert. Pendant ce temps, AT & T avait réussi à se disputer avec l’une des rares entités sur la planète qui soit plus grande qu’elle ne l’était (l’État de Californie) et n’avaient finalement pas gagné le procès. pied. Mais à l’époque, Linux et bash étaient partout et BSD est aujourd’hui une niche.
7. Enfin, bash est une bonne coque (bien qu’apparemment désavoué en privé par son auteur original) et 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 de super ensemble pour posix-sh, même si appelé comme / bin / sh émulera entièrement posix-sh. Posix-sh était la "norme" pour les systèmes commerciaux Unix en tant que shell à dénominateur commun. Donc, quelque chose qui commence là-bas et s’appuie sur lui commence par beaucoup.

Parce que Linux n’est que le noyau (et le support nécessaire), GNU fournit (ou a fourni) tous les clones logiciels Unix de base qui rendent utilisable ce que nous appelons «Linux». Bash est le shell du projet GNU, écrit comme un clone de l'ancien shell Bourne (sh) d'Unix version 7.

Selon un sondage effectué par unix.com, ce n'est pas beaucoup plus loin que ksh.
/ bin / sh 83 8,96%
/ bin / csh 36 3,89%
/ bin / ksh 370 39,96%
/ bin / tcsh 36 3,89%
/ bin / bash 401 43,30%

Bash est largement accepté en raison de son riche ensemble de fonctionnalités. Il adopte également les caractéristiques d'autres coques telles que C-shell et Korn-shell. S'il vous plaît jeter un oeil à cet ensemble de fonctionnalités.

Parce que 'bash' est compatible à 100% 'sh / ksh' et que 'ksh' est le shell POSIX.

Donc, si vous voulez un système compatible POSIX et que vous êtes sur Linux, vous utilisez bash.

Si vous utilisez un unix commercial, vous obtenez généralement ksh comme shell par défaut (parfois tout simplement vieux sh). Pour une raison quelconque, Sun utilise toujours le flocon de csh shell csh.

L'avantage est la portabilité: un fichier .sh écrit pour hp-ux ou AIX a de bonnes chances de fonctionner en tant que «bash» linux sans aucune modification.

Et pour ajouter à toutes les autres réponses: zshne signifie pas être compatible avec les versions antérieures. Vous pouvez probablement le configurer pour qu'il soit compatible, mais vous perdez alors ses fonctionnalités.

Je utilise zshcomme ma coquille interactive régulière, mais bash/ dashsemble plus sain d' esprit pour moi comme un langage de script shell; ils font moins de magie et sont plus prévisibles ... c'est plus important pour moi quand j'écris un script qui doit fonctionner pendant plusieurs années.

Juste pour confondre les choses, la shcommande est parfois simplement un lien symbolique vers un autre programme shell, tel que ash, bashou dash.

Ubuntu y avait l'habitude de se lier bash, car il bashest conçu pour exécuter n'importe quel script shell Bourne conforme.

Cependant, récemment, Ubuntu est passé à avoir un shlien vers dash. dashest conçu pour exécuter des bashscripts (et donc également des shscripts), mais il est conçu pour être utilisé uniquement pour les scripts, de sorte qu'il manque les fonctionnalités interactives de bash. Cela le rend plus petit et (peut-être) plus rapide.