Modification juin 2019 : Apple passe à zsh pour macOS Catalina (v10.15).
-
Il y a de bonnes réponses ici, jusqu'à présent.
J'ajouterai un peu d'histoire pour noter que bash n'était pas la valeur par défaut avant la version 10.3 Panther. Avant cela, tcsh était le shell par défaut sur Mac OS X v10.0 à v10.2.
Avant cela, il y avait le Mac OS X Server 1.0 original (la première version de Rhapsody). Mac OS X Server est issu de l'acquisition de NeXTSTEP, et incluait un userland 4.4BSD. Les cinglés de Berkeley adoraient leur csh, et Mac OS X Server 1.0 utilisait ce même userland 4.4BSD avec ce même csh dans la version originale. Pendant ce temps, les variantes commerciales de SysV utilisaient le shell Bourne et parfois Korn. Linux a adopté Bash très tôt, car c'était un shell sous licence GPL et compatible avec Bourne de la FSF.
Le passage à tcsh faisait partie de l'amélioration continue d'Apple du noyau Darwin, et une grande partie de cela comprenait le remplacement de beaucoup de l'userland 4.4BSD userland avec FreeBSD (et des morceaux de NetBSD, etc.), puisque ces projets sont activement maintenus.
Mais rien de tout cela ne répond à votre question réelle, qui est : pourquoi utilise-t-il encore bash, cet ancien shell croustillant des temps anciens ?
La réponse est que bash n'est pas vieux et croustillant. Bash est un exemple de l'évolution d'un logiciel pour faire ce que ses utilisateurs ont besoin qu'il fasse. Il est compatible avec le Bourne shell (besoin originel), il a incorporé des fonctionnalités utiles de csh (historique des commandes, contrôle des tâches, etc), et adopte des mécanismes d'autres langages pour améliorer sa syntaxe de programmation. L'équipe publie encore périodiquement de nouvelles fonctionnalités et améliorations, mais fondamentalement, il s'agit toujours du même shell que celui dont Kernigan et Pike ont parlé dans The Unix Programming Environment.
Et pourquoi le shell Unix est-il toujours utilisé, quelle que soit sa version ou son implémentation réelle ? Parce que rien de mieux n'est encore arrivé.
Apple a besoin d'un shell. Bash en fournit le meilleur à ce jour. Apple peut choisir de dépenser de l'argent pour développer un nouveau shell et n'en tirer aucune augmentation de revenus, ou mettre plus d'argent et de développement dans d'autres améliorations. Quiconque achète un Mac et s'attend à utiliser Terminal.app sait ce qu'il obtient : un shell similaire à celui de sa boîte Ubuntu à la maison, un shell similaire à celui de son serveur Red Hat au travail, ou un shell similaire à celui qu'il utilisait sur son PDP à l'université. Personne ne crie "Donnez-nous un nouveau shell !". Bash, tout comme sh, csh, ksh, zsh et tous les autres, vous offre un environnement interactif qui peut être aussi simple ou complexe que vous le souhaitez, et c'est aussi un environnement entièrement programmable adapté à la programmation par tâches.
De même, Red Hat, Canonical, Slackware, Debian et les autres distributions Linux continueront à utiliser GNU bash pour les mêmes raisons. Il y a des choses plus importantes sur lesquelles travailler. Le monde de l'open source peut produire un nouveau shell amélioré lorsqu'un hacker intelligent décide qu'il peut faire mieux pour répondre aux besoins du nouveau millénaire. Il se peut même qu'il y en ait déjà quelques-uns qui flottent, n'attendant que d'être adoptés.
Dès que l'un d'entre eux gagnera en usage courant, vous pouvez parier votre doux egrep '^[[:alpha :]]{2}sThere may even be a few floating around already, just waiting for adoption.
As soon as one of these gains mainstream usage, you can bet your sweet egrep '^[[:alpha:]]{2}s$' /usr/share/dict/words | sed s/^../as/ | uniq that Apple will add it to the OS.apos ; /usr/share/dict/words | sed s/^../as/ | uniq qu'Apple l'ajoutera au système d'exploitation. Et si suffisamment d'utilisateurs commencent à l'utiliser régulièrement et à y basculer leurs shells par défaut, Apple en fera le shell par défaut.
En attendant, bash, c'est la vie.