Pourquoi bash est-il le shell par défaut dans la plupart des systèmes d'exploitation?

Pourquoi bash est-il le shell par défaut de la plupart des systèmes d’exploitation (Ubuntu, Fedora, OSX, etc.)? Pourquoi de nombreux utilisateurs avancés utilisent-ils principalement zsh? Si c'est si bon, pourquoi n'est-ce pas le défaut?

J'utilise les deux je ne vois pas de différence car toutes mes tâches sont simples :)

J'ai lu quelque chose à ce sujet et la conclusion semble être que c'est le shell par défaut de GNU (utilisé par la plupart des systèmes d'exploitation basés sur Linux), et qu'il est donc simplement inclus dans le cadre de GNU, tout en bénéficiant de 20 années de développement. stable et bien arrondi, c’est tout simplement le meilleur appareil polyvalent, répondant aux besoins de tous, à l’exception des utilisateurs les plus avancés.

Pour plus d'informations, lisez Pourquoi bash est-il standard sur Linux? (même question sous Unix et Linux).

Juste pour ajouter un peu plus à cela, il y a beaucoup d'autres coquilles à essayer, si vous êtes intéressé, voici quelques unes de cette réponse :

• Zsh dispose d'installations interactives plus avancées, mais quelques bizarreries en matière de script (moins maintenant que dans le passé). Au début ou au milieu des années 90, lorsque Linux en était à ses balbutiements, zsh était pratiquement inconnu.

• Ksh était le standard de facto sur les ordinateurs commerciaux depuis le milieu des années 1980, mais c'était un logiciel propriétaire jusqu'en 2000, donc pas une option sous Linux. En outre, ksh avait des capacités d'édition en ligne de commande inférieures à celles de bash.

• Pdksh , un clone libre de ksh, aurait été une option, mais il était mal connu et ses capacités d’édition en ligne de commande étaient médiocres. (Pdksh n'est plus un projet très actif, même s'il est encore utilisé dans certains BSD, maintenant qu'ATT ksh est libre.)

• Certaines distributions installent une variante de cendres en tant que /bin/sh. Ash (c’est-à-dire toutes les coquilles de la famille des cendres) est conçu pour être petit et rapide, sans fonctions interactives (uniquement pour l’édition de scripts). La reprise des cendres est relativement récente; dans les années 90, les variantes existantes manquaient de nombreuses fonctionnalités.

• Tcsh était le shell interactif le plus avancé jusqu’à l’arrivée de zsh, mais il est incompatible avec sh et moins performant avec les scripts .

The Bourne Shell ( sh retour dans la journée) de la branche AT & T d'Unix a été amélioré et supplantée par le Korn Shell, ksh . ksh est également sorti d'AT & T Bell Labs et n'était pas sous GPL (la version actuelle est Eclipse Public License). C-shell, csh est issu de la version Unix de Berkeley et n’est pas non plus une licence GPL (licence BSD) et utilise une syntaxe différente de celle de sh. Z-shell, zsh est une amélioration de sh mais pas de GPL (licence de type MIT). Bash était une amélioration de sh, utilisait la GPL et de GNU. Juste sous licence, Bash aurait probablement été le choix d’un système d’exploitation sous GPL. En particulier, une coque étant une partie essentielle d’une distribution.

Mais Bash était aussi un projet GNU, lui donnant, je pense, un développement plus actif et des contributions plus faciles qu’un produit hérité de Berkeley Unix ou d’AT & T Unix. On pourrait très bien dire que zsh est et a été un meilleur shell que Bash, mais pas assez pour vaincre sa licence différente et son statut de projet non-GNU.

À l'époque où les distributions Linux apparaissaient pour la première fois et choisissaient leur shell par défaut (du début au milieu des années 90), il n'y avait pas de github (2008) ni même de SourceForge (1999). À ce stade, je pense que les projets GNU avaient un réel avantage sur les projets non-GNU en ce qu’ils se faisaient remarquer et attiraient de nouveaux développeurs. Ainsi, les distributions pourraient sembler meilleures à Z-shell, mais elles devraient également offrir à Bash un support et une maintenance de qualité, ainsi que davantage de fonctionnalités, ce qui lui permettra de rattraper zsh.

Maintenant que Bash a un statut par défaut de plusieurs années, c'est devenu un standard de facto, avec des livres écrits à ce sujet. Il existe un livre qui couvre à la fois Bash et Z-shell , mais aucun livre ne le couvre exclusivement, alors qu'il en existe plusieurs qui le font pour Bash.

Et à ce stade, si les distributions modifiaient la valeur par défaut pour les mises à niveau d'un système existant, les configurations seraient cassées car certains fichiers d'initialisation ont des noms différents (par exemple .bashrc ou .zshrc) et le contenu des fichiers peut avoir une syntaxe incompatible. Ils seraient donc très réticents à le faire, laissant les nouveaux téléchargements utilisant zsh par défaut et les mises à niveau utilisant bash. Deux valeurs par défaut différentes pour la même distribution ne sont probablement pas souhaitables et les utilisateurs / entreprises ne veulent pas non plus gérer.

Les langages shell Unix sont tous laids. Certains en particulier ( csh), certains peut-être un peu moins ( ksh? Je ne sais pas en fait), mais en ce qui concerne des aspects comme la lisibilité et la rigidité pour les grands projets, aucun d'entre eux ne peut s'approcher de langages généraux bien conçus, tels que Python, C # ou Haskell. Ainsi, lorsque vous voulez quelque chose de solide, vous ne choisirez jamais aucune des saveurs de coque.

Vous les choisissez quand vous voulez faire rapidement des choses simples. Pour cela, vous avez besoin de:

• Syntaxe concise et cohérence suffisante pour que vous puissiez réellement la mémoriser (il est difficile de rechercher des opérateurs abrégés). Il est très important que votre shell soit installé partout, car vous ne voudriez pas mémoriser plus d’un de ces monstres kludge.
• De bonnes fonctionnalités interactives vous permettent de pirater directement le terminal et de faire fonctionner des éléments sans avoir à basculer entre plusieurs fichiers de script.
• La possibilité de récupérer n'importe quel extrait de script de n'importe où et de le faire fonctionner. shLa compatibilité est un gros plus ici, et encore une fois, le plus populaire, mieux c'est.

Vous voyez donc que la popularité est un point plus important dans ces langages shell que pour les langages à usage général. Par conséquent, même si le kshlangage est un peu «meilleur» en tant que tel, il n’ya pas vraiment d’avantage à l’utiliser sibash c’est un peu plus populaire (ce qui était le cas dans le secteur concerné, car il a été choisi pour la première fois par défaut). pour GNU).

Les personnes qui effectuent le changement sont délibérées et suffisamment expérimentées pour gérer facilement le basculement vers leur shell favori. OTOH, une recrue qui est forcée de travailler avec un shell moins populaire sera rapidement déconcertée si elle demande quelque chose à Internet et que cela ne fonctionne pas. Par conséquent, toute distribution qui ne vise pas uniquement les anciens combattants Unix prend un risque certain si elle produit autre chose que bashla norme, une étape dont relativement peu de personnes bénéficieraient (et seulement un peu).

1. C'était là quand c'était nécessaire
2. Les utilisateurs débutants peuvent passer une semaine à personnaliser leur invite.
3. Les cas d'utilisation courants sont assez bons (le plus courant étant de lancer une seule commande)
4. Quand ce n'est pas assez bon, perl, python et lua peuvent prendre le relais.
5. Perl fait un shell interactif terrible
6. Bien que fish, ksh ou zsh puissent théoriquement être une meilleure coque, il n’ya pas assez d’améliorations à me préoccuper lorsque Perl fonctionne si bien ou que la portabilité pose problème, c’est pourquoi je vise de toute façon un objectif rapide.

"Critical Mass" est la réponse principale, IMO. Bash n’est pas uniquement destiné au travail en ligne de commande, il s’agit de la génération de scripts et il existe un très grand nombre de scripts Bash. Peu importe la solution alternative actuellement offerte pour l'interaction, la nécessité de pouvoir simplement "brancher et jouer" ces scripts l'emporte sur ces avantages. En tant que tel, le seul shell qui peut de manière réaliste dissoudre Bash est celui qui est complètement compatible avec les versions antérieures et le candidat le plus probable est ... la prochaine version de Bash.