Bash a deux atouts complètement différents.

1. C'est une belle Shell. C'est l'un des 2 shells (l'autre étant zsh) qui intègrent certaines des fonctionnalités les plus cool de l'environnement de travail. csh des caractéristiques telles que ! substitution de l'histoire dans la syntaxe posix. Il possède de nombreuses extensions, y compris les tableaux.

2. Il s'agit du Shell de la FSF/GNU. Dans le monde de l'open source, cela lui donne une sorte de cachet.

Je dois également ajouter que ce n'est pas toujours le cas par défaut. ash est souvent utilisé comme /bin/sh, de sorte que pendant que bash peut être le Shell interactif, ash est le Shell "exécutez simplement le fichier de commandes". Cela s'explique par le fait que ash est plus petit et plus rapide, et contient les fonctionnalités posix, c'est donc un sous-ensemble approprié. L'utilisation de ash en tant que Shell interactif est parfois problématique. Sous NetBSD, par exemple, il fonctionne bien, car il est construit avec toutes les fonctionnalités. C'est en quelque sorte leur Shell unique alors que bash est un paquet externe. Mais sous Linux ash est généralement considéré comme non interactif, et ils le compilent donc sans l'historique et sans l'édition de ligne (importante), en partant du principe qu'il est juste utilisé pour exécuter ces énormes gnu configure scripts.

L'histoire de deux coquilles

La véritable histoire de la Shell

UPDATE : Il existe une histoire inexacte du Shell qui a été copiée d'un endroit à l'autre sur le web, et les gens y croient, ce qui est compréhensible. J'essaierai de donner une version exacte et de fournir quelques liens pour l'étayer ici.

1. Le premier Shell n'était certainement pas le Shell de Bourne, mais a été écrit par Ken Thompson lui-même et distribué en V6, qui est la version qu'AT&T a envoyée à diverses universités et laboratoires gouvernementaux. C'est ce qui a mis Unix sur la carte. Elle contenait tous les éléments de base, <, >, >>, |, & mais il n'avait qu'une simple goto la syntaxe de contrôle par l'intermédiaire d'un programme externe qui recherche sur l'entrée standard. Il n'y avait pas de Shell Shell complexes à l'époque. Plus tard, les shells ouvriront l'entrée de commande sur un fd séparé. Cela peut paraître simple aujourd'hui, mais dans le film d'horreur qu'était l'informatique des années 1970, c'était ce qu'il y avait de mieux sur terre. Croyez-le ou non, cet ancien Shell a son propre flux twitter aujourd'hui et, bien sûr, une page d'accueil .
2. Le deuxième Shell était csh , écrit (comme l'a fait vi ) par Bill Joy à l'UCB. C'était avant GNU readline et NetBSD editline, et il devait donc sembler parfaitement raisonnable de faire de l'histoire avec le programme ! syntaxe. Csh a ajouté la plupart des fonctionnalités actuelles de Shell mais avec la syntaxe csh. csh n'a pas modifié la syntaxe gratuitement ou non. Il était en fait compatible avec le Shell de Thompson, et incluait à l'origine le code source de TS.
3. Le troisième Shell était le Shell de Bourne, avec une syntaxe différente. Unix était développé en parallèle à l'UCB et à l'AT&T. Ce Shell avait un allocateur de mémoire bizarre (je pense qu'il utilisait simplement plus de mémoire, bloquait SIGSEGV, faisait un nouveau brk(2), puis réessayait) qui le rendait difficile à exécuter sur les nouveaux ports Unix, donc osh y csh est restée populaire pendant un certain temps. Il n'y avait pas d'internet et il s'agissait d'un logiciel sous licence. Stephen Bourne ne connaissait pas le Shell de Joy et Joy ne connaissait certainement pas Bourne. Il est possible que les deux shells se soient rencontrés pour la première fois lorsque UCB a reçu un VAX et une pré-version de l'application Unix/32V, aujourd'hui oublié . Je me souviens que Bill s'est plaint de l'allocation de mémoire. Notez que les deux shells étaient compatibles avec la V6 Shell. Ils ont simplement étendu la syntaxe dans des directions différentes.
4. Il existe désormais plusieurs shells incompatibles, auxquels AT&T a ajouté le shell compatible avec Bourne ksh . En fin de compte, csh avait un code source semi-disponible, mais il était bloqué dans une procès entre AT&T et l'Université de Californie . Pourtant, c'était l'époque glorieuse de BSD Unix, car les entreprises sophistiquées qui pouvaient se permettre de payer 50 000 dollars achetaient la licence AT&T mais installaient les distributions BSD 4.x, tandis que les universités bénéficiaient de la gratuité.
5. Dans cette situation où de nombreuses questions juridiques et techniques se posent, plusieurs mises en œuvre indépendantes ont été entreprises. Au moins autant d'entre elles ont suivi la csh comme la syntaxe Bourne Shell, et certains ont fusionné les deux. Vous aviez au moins tcsh , zsh , bash y ash . La syntaxe Bourne était "officielle", puisqu'elle faisait partie des versions AT&T, mais à l'époque, BSD était très important, et Sun, initialement BSD, distribuait une bonne partie des logiciels Unix que le monde rencontrait.
6. En partie à cause du procès de l'USL, la FSF et Linux ont eu le champ libre. Entre-temps, AT&T avait réussi à se battre avec l'une des rares entités sur terre plus grande qu'elle (l'État de Californie) et n'avait finalement pas gagné le procès, ce qui a permis à la distribution BSD de s'appuyer sur une base juridique solide. Mais à ce moment-là, Linux et bash étaient partout, et aujourd'hui BSD est une niche.
7. Enfin, bash est un bon Shell (bien qu'apparemment désavoué en privé par son auteur original) et il mérite pleinement le crédit de son propre succès. csh aurait été éclipsé par tcsh et zsh même si ash, bash, et ksh n'avaient pas gagné la guerre de la syntaxe.

Pour compléter ce qu'a dit @DigitalRoss

• Bash est un remplacement complet de posix-sh, au point que si on l'appelle /bin/sh, il émule entièrement posix-sh. Posix-sh était le "standard" pour les systèmes unix commerciaux en tant que dénominateur commun Shell. Donc, quelque chose qui commence par là et se développe à partir de là commence avec beaucoup de choses.

D'après une enquête de unix.com, il n'est pas beaucoup plus avancé que ksh.
/bin/sh 83 8,96%
/bin/csh 36 3.89%
/bin/ksh 370 39,96%
/bin/tcsh 36 3,89%
/bin/bash 401 43,30%

Bash est largement accepté en raison de la richesse de ses fonctionnalités. Il reprend également des fonctionnalités d'autres shells comme C-Shell et Korn-Shell. Jetez un coup d'œil à ces de caractéristiques.

Parce que 'bash' est 100% compatible avec 'sh/ksh' et 'ksh' est le POSIX Shell.

Ainsi, si vous voulez un système compatible POSIX et que vous êtes sous Linux, vous utilisez bash.

Si vous êtes sur un unix commercial, vous avez généralement ksh comme Shell par défaut (parfois simplement le bon vieux sh). Pour une raison ou une autre, Sun utilise toujours par défaut le fade csh c-Shell.

L'avantage est la portabilité : un .sh écrit pour hp-ux ou AIX a de bonnes chances de fonctionner comme un "bash" linux sans aucune modification.