Skip to content

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

Solution:

J’ai fait quelques lectures à ce sujet et la conclusion semble être qu’il s’agit du 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 emballé dans le cadre de GNU, tout en ayant 20 ans de développement derrière lui, ce qui en fait stable et bien arrondi, c’est tout simplement le meilleur polyvalent, répondant aux besoins de tous, sauf des utilisateurs les plus avancés.

Pour en savoir plus, lisez Pourquoi bash est-il standard sous Linux ? (la même question sur Unix & Linux).

Juste pour ajouter un peu plus à cela, il y a beaucoup d’autres shells à essayer, si cela vous intéresse, en voici quelques-uns de cette réponse :

  • Zsh a des installations interactives plus avancées, mais quelques bizarreries en ce qui concerne les scripts (moins maintenant qu’à l’époque). Du début au milieu des années 90, lorsque Linux en était à ses balbutiements, zsh était pratiquement inconnu.

  • Ksh était la norme de facto sur les unices commerciaux depuis le milieu des années 1980, mais c’était un logiciel propriétaire jusqu’en 2000, donc pas une option sur Linux. De plus, ksh avait des capacités d’édition de ligne de commande inférieures à celles de bash.

  • Pdksh, un clone gratuit de ksh, aurait été une option, mais il n’était pas bien connu et avait de faibles capacités d’édition en ligne de commande. (Pdksh n’est plus un projet très actif, même s’il est toujours utilisé dans certains BSD, maintenant qu’ATT ksh est gratuit.)

  • Certaines distributions installent une variante ash comme
    /bin/sh. Ash (par quoi je veux dire n’importe quelle famille de coques en vrac appelées ash) est conçu pour être petit et rapide, sans fonctionnalités interactives (c’est uniquement pour l’édition de scripts). Le renouveau du frêne est relativement récent ; dans les années 1990, les variantes existantes manquaient de beaucoup de fonctionnalités.

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

Le coquillage Bourne (sh à l’époque) de la branche AT&T d’Unix a été amélioré et remplacé par le Korn Shell, ksh. ksh est également sorti d’AT&T Bell Labs et n’était pas GPL (la version actuelle est la licence publique Eclipse). La coque C, csh est sorti de la version Berkeley d’Unix et n’était pas non plus GPL (licence BSD) et utilisait également une syntaxe différente de celle de sh. La coque Z, zsh est une amélioration de sh mais pas de la GPL (licence de type MIT). Bash était une amélioration de sh, utilisait la GPL et de GNU. Rien que sur la licence, Bash aurait probablement été le choix pour un système d’exploitation GPL. En particulier avec un shell faisant partie intégrante d’une distribution.

Mais Bash était aussi un projet GNU, lui donnant, je pense, un développement plus actif et rendant les contributions plus faciles qu’un produit hérité de Berkeley Unix ou AT&T Unix. Un très bon argument pourrait être avancé que zsh est et a été un meilleur shell que Bash, mais pas assez pour surmonter 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 pour se faire remarquer, dessiner et inclure de nouveaux développeurs. Ainsi, les distributions pourraient considérer le Z-shell comme meilleur, mais s’attendre également à ce que Bash bénéficie d’un bon support et d’une bonne maintenance à l’avenir, et dispose également de plus de fonctionnalités, lui permettant de rattraper zsh.

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

Et à ce stade, si les distributions changeaient la valeur par défaut pour les mises à niveau d’un système existant, cela interromprait les configurations car certains fichiers d’initialisation ont des noms différents (par exemple .bashrc contre .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 avec zsh par défaut et les mises à niveau avec bash. Deux valeurs par défaut différentes pour la même distribution sont quelque chose qu’ils ne veulent probablement pas avoir à prendre en charge et que les utilisateurs/entreprises ne veulent pas non plus traiter.



Articles Similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.