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

35

Pourquoi bash est-il le shell par défaut dans la plupart des systèmes d'exploitation (Ubuntu, Fedora, OSX, etc.)? Pourquoi est-ce que beaucoup d'utilisateurs avancés utilisent 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 pour toutes mes tâches sont simples:)

    
posée Talal 20.06.2015 - 21:52
la source

5 réponses

31

J'ai fait quelques lectures à ce sujet et la conclusion semble être que c'est le shell par défaut de GNU (utilisé par la plupart des systèmes Linux OS), et donc simplement intégré à GNU, tout en ayant 20 ans de développement derrière lui, ce qui le rend stable et complet, il est tout simplement le meilleur tout en répondant aux besoins des utilisateurs les plus avancés. p>

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

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

  
  • Zsh a plus avancé   installations interactives, mais quelques bizarreries en matière de script   (moins maintenant qu'à l'époque). Au début des années 1990, quand   Linux en était à ses débuts, zsh était pratiquement inconnu.

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

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

  •   
  • Certaines distributions installent un    ash variant comme    /bin/sh . Ash (par lequel je veux dire n'importe quelle famille de coquillages   appelé cendres) est conçu pour être petit et rapide, sans interactif   fonctionnalités (uniquement pour éditer des scripts). La renaissance des cendres est   relativement récent; dans les années 1990, les variantes existantes manquaient beaucoup de   fonctionnalités.

  •   
  • Tcsh était le plus avancé   shell interactif jusqu'à l'arrivée de zsh, mais incompatible avec sh   et pas si bien avec   scripting .

  •   
    
réponse donnée Mark Kirby 20.06.2015 - 22:25
la source
8

Le shell Bourne ( sh ) de la branche AT & T d'Unix a été amélioré et remplacé par le shell Korn, ksh . ksh est également sorti des laboratoires AT & amp; Bell et n'était pas GPL (la version actuelle est la licence publique Eclipse). Le C-shell, csh est sorti de la version Berkeley d'Unix et n'était pas non plus sous licence GPL (licence BSD) et utilisait également une syntaxe différente de sh. Le shell Z, zsh est une amélioration sur sh mais pas sur GPL (licence de type MIT). Bash était une amélioration sur sh, utilisait la GPL et GNU. Juste sur licence seule Bash aurait probablement été le choix pour un système d'exploitation GPL. En particulier avec un shell qui fait 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 exemple pourrait être fait que zsh est et a été un meilleur shell que Bash, mais pas assez pour surmonter ses différents statuts de licence et de projet non GNU.

À la première apparition des distributions Linux et en choisissant 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 par rapport aux projets non-GNU pour se faire remarquer, dessiner et inclure de nouveaux développeurs. Ainsi, les distributions pourraient mieux considérer le Z-shell, mais espèrent également que Bash bénéficiera d'un bon support et d'une maintenance plus poussée, ainsi que de fonctionnalités supplémentaires, lui permettant de rattraper zsh.

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

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

    
réponse donnée Scooter 21.06.2015 - 06:28
la source
1

Les langages shell Unix sont tous laids. Certains en particulier ( csh ), d'autres peut-être un peu moins ( ksh ? Je ne sais pas en fait), mais en réalité, pour des aspects tels que la lisibilité et la rigidité des gros projets, aucun conçu des langages à usage général tels que Python, C # ou Haskell. Donc, quand vous voulez quelque chose de solide, vous ne choisirez jamais aucune des saveurs du shell.

Vous les choisissez quand vous voulez rapidement faire des choses simples. Pour cela, il vous faut:

  • Syntaxe concise et cohérence suffisante pour que vous puissiez la mémoriser (il est difficile de rechercher des opérateurs raccourcis). Il est très important que votre shell soit installé partout, car vous ne préféreriez pas mémoriser plus d'un de ces monstres kludge.
  • Bonnes fonctionnalités interactives, vous pouvez donc pirater directement le terminal et obtenir des fonctionnalités sans avoir à passer d’un fichier de script à un autre.
  • La possibilité de saisir n'importe quel fragment de script depuis n'importe où et de le faire fonctionner. La compatibilité sh est un gros avantage ici, et encore une fois, le plus populaire est le mieux.

Vous voyez, la popularité est plutôt un point plus important dans ces langages shell que dans les langages d'usage général. Par conséquent, même si ksh est un peu "meilleur" en tant que langage en soi, il n'y a pas vraiment d'avantage à l'utiliser si bash est juste un peu plus populaire (ce qui était le cas dans le secteur concerné a été choisi pour la première fois par défaut pour GNU).

Les personnes qui font le changement sont délibérées et suffisamment expérimentées pour gérer facilement le basculement vers leur shell préféré. OTOH, une recrue forcée de travailler avec un shell moins populaire, sera vite déconcertée si elle demande quelque chose à Internet et que cela ne fonctionne pas. Par conséquent, toute distribution qui ne s'adresse pas uniquement aux vétérans Unix prend un certain risque si elle ne fait rien d'autre que bash la norme, une étape dont peu de personnes bénéficieraient (et seulement un peu).

    
réponse donnée leftaroundabout 21.06.2015 - 01:49
la source
1
  1. C'était là quand il le fallait
  2. Les utilisateurs débutants peuvent passer une semaine à personnaliser leur message.
  3. Les cas d’utilisation courants, c’est suffisant (le plus courant étant de lancer une seule commande)
  4. Là où cela ne suffit pas, perl, python et lua peuvent prendre la relève.
  5. perl fait un shell interactif terrible
  6. Bien que fish, ksh ou zsh puisse théoriquement être un meilleur shell, il n’ya pas d’amélioration suffisante pour que je le dérange lorsque Perl fonctionne si bien ou que la portabilité pose problème, donc je cible de toute façon.
réponse donnée hildred 21.06.2015 - 06:06
la source
0

"Critical Mass" est la réponse principale, IMO. Bash ne sert pas uniquement au travail en ligne de commande, mais aussi aux scripts et à un énorme nombre de scripts Bash. Peu importe à quel point une alternative est désormais possible pour l'interaction, le besoin de pouvoir simplement «brancher» ces scripts l'emporte sur ces avantages. En tant que tel, le seul shell capable de renverser Bash de façon réaliste est désormais totalement compatible avec la version précédente et le candidat le plus probable est la prochaine version de Bash.

    
réponse donnée Nagora 21.06.2015 - 00:24
la source

Lire d'autres questions sur les étiquettes