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 dans la plupart des systèmes d'exploitation (Ubuntu, Fedora, OSX, etc.)? Pourquoi beaucoup d'utilisateurs avancés utilisent-ils principalement zsh? Si c'est si bon, pourquoi n'est-ce pas le cas par défaut?
J'utilise les deux je ne vois pas de différence car toutes mes tâches sont simples :)
J'ai lu un peu à 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 avec 20 années de développement derrière lui rendant stable et bien arrondi, il est tout simplement le meilleur tout rond, répondant aux besoins de tous les utilisateurs, sauf les plus avancés.
Pour plus d'informations, lisez Pourquoi la norme bash 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 cela vous intéresse, en voici quelques unes de cette réponse :
Zsh a des 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 n'était pas bien 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 toujours utilisé dans certains BSD, maintenant qu'ATT ksh est libre.)
Certaines distributions installent une variante ash sous la forme
/bin/sh. Ash (c’est-à-dire toute cueillette de coquilles appelée 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'à ce que zsh apparaisse, mais il est incompatible avec sh et pas si bien avec les scripts .
Le Bourne Shell ( sh de la journée) de la branche AT & T d’Unix a été amélioré et remplacé par le Korn Shell, ksh . ksh est également sorti de AT & T Bell Labs et n’était pas sous licence GPL (la version actuelle est Eclipse Public License). Le C-Shell, csh est sorti de la version Unix de Berkeley et n'était pas non plus sous GPL (licence BSD) et utilisait une syntaxe différente de celle de sh. Le Z-Shell, zsh est une amélioration sur sh mais pas sur GPL (licence semblable à 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 avec une coquille étant une partie essentielle d'une distribution.
Mais Bash était aussi un projet deGNU, lui donnant, je pense, un développement plus actif et rendant les 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, j'estime que GNU projets _ avaient un réel avantage sur les projets non GNU en ce qu'ils se faisaient remarquer, attiraient de nouveaux développeurs. Ainsi, les distributions pourraient considérer Z-Shell comme étant meilleures, 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 y a n livre couvrant à 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 Unix Shell sont tous laids. Certains en particulier (csh), d'autres peut-être un peu moins (ksh? Je ne sais pas en fait), mais vraiment 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 Shell.
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, plus c'est populaire, mieux c'est.
Vous voyez donc que la popularité est un élément plus important dans ces langages Shell que pour les langages à usage général. Par conséquent, même si ksh est un peu "meilleur" en tant que langage en lui-même, il n’est pas tellement avantageux de l’utiliser si bash est juste un peu plus populaire (ce qui était le cas dans le secteur la valeur 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 passage à leur Shell préféré. OTOH, une recrue qui est forcée de travailler avec un Shell moins populaire, sera vite embarrassé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 certain risque si elle fait de la définition autre chose que bash, une étape dont relativement peu de personnes bénéficieraient (et seulement un peu).
- C'était là quand c'était nécessaire
- Les utilisateurs débutants peuvent passer une semaine à personnaliser leur invite.
- Les cas d'utilisation courants sont assez bons (le plus courant étant de lancer une seule commande)
- Là où cela ne suffit pas, Perl, python et lua peuvent prendre le relais.
- Perl fait un terrible shell interactif
- bien que fish, ksh ou zsh puissent théoriquement être un meilleur shell, il n’ya pas assez d’améliorations à me préoccuper lorsque Perl fonctionne si bien ou que la portabilité est un problème, je cible donc de toute façon.
"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 désormais remplacer de façon réaliste Bash est totalement compatible avec les versions antérieures et le candidat le plus probable est… la prochaine version de Bash.