Bash se usa por defecto en cada distribución de Linux que he probado, sobre alternativas como Z shell (zsh). ¿Hay alguna razón técnica o histórica para esto?

Historia (adquirida no a través de la investigación, sino por pasar demasiado tiempo saliendo con la gente de Bell Labs):

1. Al principio (si considera que el comienzo es Unix Versión 7) fue el shell Bourne. Steve Bourne fue el primero en mostrar que el shell que controlaba la interacción del usuario podría ser un programa de usuario y no una parte especial del sistema operativo. Un avance histórico. El shell en sí estaba relativamente limpio para las secuencias de comandos, pero no tenía edición de línea de comandos o control de trabajo. La Introducción de Bourne a Unix Shell sigue siendo útil para los usuarios principiantes de hoy.

   Editar : He ignorado algunas "prehistorias" de Ken Thompson y John Mashey, también de Multics. Estoy seguro de que Bourne estaba al tanto de todo este trabajo (estaba en el mismo laboratorio, 1127, en Bell Labs), pero el caparazón de Bourne fue definitivo, y el trabajo anterior tuvo poca influencia, excepto según lo interpretado por Steve Bourne. Por ejemplo, aunque Ken más tarde escribió el compilador del Plan 9 C y fue muy influyente en el Plan 9, pero el documento de Tom Duff sobre el shell del Plan 9 (rc) solo menciona el shell de Bourne, no el de Thompson.

2. El shell es solo un programa de usuario, por lo que cualquiera puede escribir uno. A medida que se estaba creando la Versión 7 de Unix en Nueva Jersey, se estaba creando Berkeley Unix en California. Bill Joy en Berkeley escribió csh, la cáscara C. Joy agregó el control del trabajo y la historia, y más tarde la edición de la línea de comandos, pero no estaba al tanto del trabajo de Bourne y, por lo tanto, basó su lenguaje en el shell Thompson (que consideré "prehistórico" en la viñeta anterior). La comunidad Unix amaba el control del trabajo, pero también amaba el lenguaje de Bourne. Para una polémica no particularmente buena contra el lenguaje csh, vea Programación de Csh considerada dañina . Durante un tiempo, muchas personas usaron cshinteractivamente sus características de control de trabajo e historial, pero usaron Bourne shpara escribir scripts. Esta situación era menos que ideal.

   Editar : Gracias a DigitalRoss por aclararme la cronología de csh. Desde que obtuve mi educación de personas que se refieren a BSD como "la herejía de Berkeley", me faltaban datos.

3. Dave Korn, de Bell Labs, realizó una brillante reingeniería del caparazón Bourne para producir el caparazón Korn (ksh). Era totalmente compatible con versiones anteriores de Bourne Shell, shpero proporcionaba un montón de mejoras invaluables. kshse convirtió en la base de un estándar POSIX y se envió estándar con el software Sun. (Esto a pesar del hecho de que Bill Joy dejó Berkeley para ayudar a encontrar a Sun y fue uno de sus líderes en software).

4. Bell Labs y AT&T fallan estúpidamente en hacer kshcódigo abierto. ksh88es ampliamente utilizado, pero tener fuentes no es legal. Ciertas personas se vuelven tan adictas que se convierten en delincuentes digitales.

   Editar : ¿Fue realmente tan estúpido? Difícil de saber Berkeley ya estaba regalando a Unix, y otras corporaciones pronto lo seguirían, pero esta era todavía la época en que los Maestros Corporativos creían en cobrar por Unix. Pero los resultados: AT&T Unix está muerto, después de haber sido vendido a varias partes varias veces. BSD y sus derivados están vivos y bien, pero estas cosas nuevas llamadas "Linux" y "GNU" tienen una fracción enorme de la mentalidad que una vez perteneció a los Laboratorios Bell.

5. La Free Software Foundation realiza una "sala limpia", desde la implementación desde cero de un shell POSIX, tomando todas las ideas de Dave Korn como entonces actuales, además del estilo FSF habitual agregando nuevas características propias, como la terminación programable. Lo llaman el shell "Bourne otra vez", o bash.

6. A mediados de la década de 1990, AT&T de código abierto ksh93, pero para entonces es demasiado tarde para una adopción generalizada. El acuerdo de licencia es extrañamente no estándar. bashy kshdivergen, y kshnunca logran una cuota de mercado acorde con su lugar en la historia.

Lecciones

• El primer producto adecuado para comercializar gana (sh).

• A las personas les encantan las nuevas funciones (control de trabajo, finalización de comandos), pero las aman aún más cuando sus viejos scripts continúan funcionando.

• Editar : Los profesores de ingeniería deben dejar la historia a los historiadores de la ciencia :-)

Bash tiene dos cosas completamente diferentes a su favor.

1. Es un buen caparazón. Es uno de quizás 2 shells (el otro es zsh) que integra algunas de las cshcaracterísticas interesantes como la !sustitución del historial en la sintaxis posix. Tiene muchas extensiones, incluidas matrices.

2. Es el shell FSF / GNU. En el mundo de código abierto, esto le da una especie de caché.

También debo agregar que no siempre es el valor predeterminado. asha menudo se usa como / bin / sh de modo que, si bien bashpuede ser el shell interactivo, ashes el shell "simplemente ejecute el archivo de comando". Esto se debe a que ashes más pequeño y más rápido, y contiene las características posix, por lo que es un subconjunto adecuado. Usarlo ashcomo un shell interactivo a veces es problemático. En, digamos, NetBSD, funciona bien, porque allí está construido con todas las características. Es una especie de shell único, mientras que bashes un paquete externo. Pero en Linux ashgeneralmente se considera no interactivo, por lo que lo compilan sin el historial y sin la edición de línea (importante) sobre la teoría de que solo se usa para ejecutar esos gnu configurescripts enormes .

Cuento de dos conchas

La verdadera historia de la concha

ACTUALIZACIÓN: Existe una historia inexacta de la copia del shell de un lugar a otro en la web, y es comprensible que la gente lo crea. Intentaré dar una versión precisa y proporcionar algunos enlaces para corroborarla aquí.

1. El primer shell ciertamente no fue el Bourne, sino que fue escrito por el propio Ken Thompson y distribuido en V6, que es la versión que AT&T envió a varias universidades y laboratorios gubernamentales. Esto es lo que puso a Unix en el mapa. Tenía todo lo básico, <, >, >>, |, &pero solo tenía una gotosintaxis de control simple a través de un programa externo que buscaba entradas estándar. No había scripts de shell complejos entonces. Los shells posteriores abrirían la entrada del comando en un fd separado. Puede parecer simple hoy, pero en la película de terror que era la informática de los años 70, era lo mejor del mundo. Lo creas o no, este antiguo shell tiene su propia transmisión de Twitter hoy y, por supuesto, una página de inicio .
2. La segunda cáscara fue csh, por escrito (como era vi) por Bill Joy en UCB. Esto fue antes de la línea de lectura de GNU y la línea de edición de NetBSD, por lo que debe haber parecido perfectamente razonable hacer historia con la !sintaxis. Csh agregó la mayoría de las funciones de shell actuales, pero con la sintaxis de csh. csh no cambió ninguna sintaxis , de forma gratuita o de otra manera. En realidad, era compatible con el shell Thompson y originalmente incluía el código fuente de TS.
3. El tercer shell era el shell Bourne, con diferente sintaxis. Unix se estaba desarrollando en paralelo en UCB y AT&T. Esta concha tenía un asignador de memoria raro (creo que acaba de utilizar más memoria, SIGSEGV atrapado, hizo un nuevo brk (2), y luego trató de nuevo) que hacía difícil correr en nuevos puertos de Unix, por lo que oshy cshse quedaron muy popular desde hace algún tiempo . No había internet y tenía licencia de SW, por lo que en ese entorno es posible que Stephen Bourne no supiera sobre el caparazón de Joy y ciertamente Joy no sabía sobre Bourne. Es posible que los dos proyectiles se hayan encontrado por primera vez cuando UCB obtuvo un VAX y una versión preliminar del ahora olvidado Unix / 32V . Recuerdo a Bill quejándose de la asignación de memoria. Tenga en cuenta que ambos shells eran compatibles con el shell V6., simplemente extendieron la sintaxis en diferentes direcciones.
4. Ahora realmente había múltiples shells incompatibles, a los cuales AT&T agregó el compatible con Bourne ksh. Eventualmente, cshtenía un código fuente semi-disponible, pero estaba atado en una demanda entre AT&T y la Universidad de California . Aún así, estos fueron los días de gloria de BSD Unix, ya que las compañías sofisticadas que podían pagar la tarifa de $ 50,000 comprarían la licencia de AT&T pero instalarían las distribuciones 4.x BSD, y las universidades la obtuvieron de forma gratuita.
5. En esta situación con muchos problemas legales y técnicos, se llevaron a cabo diversas implementaciones independientes. Al menos tantos fueron con la cshsintaxis como con la sintaxis de shell Bourne, y algunos fusionaron los dos. Tenías al menos tcsh, zsh, bash, y ash. La sintaxis de Bourne era "oficial", formando parte de los lanzamientos de AT&T, pero en aquellos días BSD era bastante importante, y Sun, inicialmente BSD, distribuía una buena cantidad de Unix SW que el mundo encontró.
6. En parte debido a la demanda de la USL, la FSF y Linux tenían un campo abierto. Mientras tanto, AT&T había logrado pelear con una de las pocas entidades en la tierra más grandes de lo que eran (El Estado de California) y al final no ganaron la demanda, y finalmente la distribución de BSD fue legalmente firme pie. Pero para entonces Linux y bash estaban en todas partes, por lo que hoy BSD es un nicho.
7. Finalmente, bash es un buen caparazón (aunque aparentemente desautorizado en privado por su autor original) y merece el crédito por su propio éxito. csh habría sido eclipsado por tcsh y zsh incluso si ash, bash y ksh no hubieran ganado la guerra de sintaxis.

Para agregar a lo que dijo @DigitalRoss

• Bash es un reemplazo completo de superconjunto para posix-sh, incluso hasta el punto si se llama como / bin / sh emulará posix-sh por completo. Posix-sh era el "estándar" para los sistemas comerciales de Unix como un shell de denominador común. Entonces, algo que comienza allí y se basa en él está comenzando con mucho.

Porque Linux es solo el Kernel (y el material de soporte requerido) mientras que GNU proporciona (o proporcionó) todos los clones básicos de software de Unix que hacen que lo que llamamos "Linux" sea utilizable. Bash es el shell del proyecto GNU escrito como un clon del antiguo shell Bourne (sh) de Unix Versión 7.

Según una encuesta de unix.com, no está mucho más lejos 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 es ampliamente aceptado debido a su rico conjunto de características. También adopta características de otros shells como C-shell y Korn-shell. Eche un vistazo a este conjunto de características.

Porque 'bash' es 100% 'sh / ksh' compatible y 'ksh' es el shell POSIX.

Entonces, si desea un sistema compatible con POSIX, y está en Linux, entonces use bash.

Si está en un Unix comercial, generalmente obtiene ksh como el shell predeterminado (a veces, simplemente, sh antiguo). Por alguna razón, Sun todavía usa de manera predeterminada el flakey csh c-shell.

La ventaja es la portabilidad. Un .sh escrito para hp-ux o AIX tiene una buena posibilidad de ejecutarse como 'bash' de Linux sin ningún cambio.

Y para agregar a todas las otras respuestas: zshno está destinado a ser compatible con versiones anteriores. Probablemente pueda configurarlo para que sea compatible, pero luego está perdiendo sus características.

Hago uso zshcomo mi shell interactivo regular, pero bash/ dashparece más sano para mí como un shell scripting idiomas; hacen menos magia y son más predecibles ... esto es más importante para mí cuando escribo un guión que debe funcionar durante varios años.

Solo para confundir las cosas, el shcomando a veces es solo un enlace simbólico a otro programa de shell, como ash, basho dash.

Ubuntu solía vincularlo bash, ya que bashestá diseñado para ejecutar cualquier script de shell Bourne compatible.

Sin embargo, recientemente, Ubuntu cambió a tener un shenlace dash. dashestá diseñado para ejecutar bashscripts (y, por lo tanto, también shscripts), pero está diseñado para usarse solo para scripts, por lo que carece de las características interactivas de bash. Eso lo hace más pequeño y (quizás) más rápido.