GNU/Linux >> Tutoriales Linux >  >> Linux

¿Por qué Bash está en todas partes (en la mayoría, si no en todas, las distribuciones de Linux)?

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

  1. Al principio (si considera que el principio es la versión 7 de Unix) fue el shell Bourne. Steve Bourne fue el primero en demostrar que el shell que controlaba la interacción del usuario podí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 la creación de secuencias de comandos, pero no tenía edición de línea de comandos ni control de trabajo. Introducción a Unix Shell de Bourne sigue siendo útil para los usuarios principiantes en la actualidad.

    Editar :He ignorado algo de "prehistoria" 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 la interpretación de Steve Bourne. Por ejemplo, aunque más tarde Ken escribió el compilador C de Plan 9 y fue muy influyente en Plan 9, el artículo de Tom Duff sobre el shell (rc) de Plan 9 menciona solo el shell de Bourne, no el de Thompson.

  2. El shell es solo un programa de usuario, por lo que cualquiera puede escribir uno. Mientras se creaba la Versión 7 de Unix en Nueva Jersey, Berkeley Unix se creaba en California. Bill Joy en Berkeley escribió csh , la capa C. Joy agregó control de trabajos e historial, y más tarde 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 caparazón de Thompson (que consideré "prehistórico" en la viñeta anterior). A la comunidad de Unix le encantaba el control de trabajos, pero también les encantaba el lenguaje de Bourne. Para una polémica no particularmente buena contra el lenguaje csh, consulte Csh Programming Considered Harmful. Durante un tiempo, mucha gente usó csh interactivamente por sus funciones de historial y control de trabajos, pero usó el sh de Bourne para escribir guiones. Esta situación era menos que ideal.

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

  3. Dave Korn en Bell Labs hizo una reingeniería brillante del caparazón Bourne para producir el caparazón Korn (ksh). Era totalmente compatible con versiones anteriores de Bourne shell sh pero proporcionó una gran cantidad de mejoras invaluables. ksh se convirtió en la base de un estándar POSIX y se envió como estándar con el software de Sun. (Esto a pesar del hecho de que Bill Joy dejó Berkeley para ayudar a fundar Sun y fue uno de los principales desarrolladores de software).

  4. Bell Labs y AT&T fallan estúpidamente en hacer ksh fuente abierta. ksh88 es ampliamente utilizado, pero tener fuentes no es legal. Ciertas personas se vuelven tan adictas que se convierten en delincuentes digitales.

    Editar :¿Fue esto realmente tan estúpido? Difícil de saber. Berkeley ya estaba regalando Unix, y otras corporaciones pronto lo seguirían, pero esta era todavía la era en la 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 advenedizas llamadas "Linux" y "GNU" tienen una gran fracción de participación mental que una vez perteneció a Bell Labs.

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

  6. A mediados de la década de 1990, AT&T abrió ksh93 , pero para entonces ya es demasiado tarde para una adopción generalizada. El acuerdo de licencia es extrañamente no estándar. bash y ksh divergen, y ksh nunca alcanza una cuota de mercado acorde con su lugar en la historia.

Lecciones:

  • El primer producto adecuado en el mercado gana (sh).

  • A la gente le encantan las funciones nuevas (control de trabajos, finalización de comandos), pero las aman aún más cuando sus antiguos scripts siguen funcionando.

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


Bash tiene dos cosas completamente diferentes a su favor.

  1. Es una concha fina. Es uno de quizás 2 shells (el otro es zsh) que integran algunos de los geniales csh características como ! sustitución de la historia en la sintaxis posix. Tiene muchas extensiones, incluidas matrices.

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

También debo agregar que no siempre es el predeterminado. ash se usa a menudo como /bin/sh de modo que mientras bash puede ser el shell interactivo, ash es el shell "simplemente ejecute el archivo de comando". Esto se debe a que ash es más pequeño y más rápido, y contiene las funciones posix, por lo que es un subconjunto adecuado. Usando ash como caparazón interactivo a veces es problemático. En, digamos, NetBSD, funciona bien, porque está integrado con todas las funciones. Es una especie de caparazón mientras que bash es un paquete externo. Pero en Linux ash generalmente se considera no interactivo, por lo que lo compilan sin el historial y sin la edición de línea (importante) en la teoría de que solo se usa para ejecutar esos enormes gnu configure guiones.

Historia de dos conchas

La verdadera historia de la concha

ACTUALIZAR: Hay una historia inexacta de la copia del caparazón 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 corroborarlo aquí.

  1. El primer caparazón ciertamente no fue el caparazón Bourne, sino que fue escrito por el mismo 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 goto simple sintaxis de control a través de un programa externo que buscaba en la entrada estándar. Entonces no había scripts de shell complejos. Los shells posteriores abrirían la entrada de comando en un fd separado. Puede parecer simple hoy, pero en la película de terror que fue la informática de 1970, fue lo mejor del mundo. Lo crea o no, este antiguo caparazón tiene su propio twitter hoy y, por supuesto, una página de inicio.
  2. El segundo caparazón era csh , escrito (como estaba vi ) por Bill Joy en UCB. Esto fue antes de GNU readline y NetBSD editline, por lo que debe haber parecido perfectamente razonable hacer historia con el ! sintaxis. Csh agregó la mayoría de las funciones de shell actuales pero con sintaxis csh. csh no cambió ninguna sintaxis , gratuitamente o de otra manera. En realidad, era compatible con versiones anteriores del shell de Thompson y originalmente incluía el código fuente de TS.
  3. El tercer shell era el shell Bourne, con una sintaxis diferente. Unix se estaba desarrollando en paralelo en UCB y AT&T. Este shell tenía un asignador de memoria extraño (creo que solo usó más memoria, atrapó SIGSEGV, hizo un nuevo brk (2) y luego volvió a intentarlo) que dificultó la ejecución en nuevos puertos Unix, así que osh y csh siguió siendo popular durante algún tiempo. No había Internet y tenía licencia SW, por lo que en ese entorno es posible que Stephen Bourne no supiera sobre el caparazón de Joy y ciertamente Joy no supiera sobre Bourne. Es posible que los dos proyectiles se conocieron por primera vez cuando UCB obtuvo un VAX y una versión preliminar del ahora olvidado Unix/32V. Recuerdo que Bill se quejó de la asignación de memoria. Tenga en cuenta que ambos shells eran compatibles con versiones anteriores del shell V6 , simplemente extendieron la sintaxis en diferentes direcciones.
  4. Ahora realmente había múltiples shells incompatibles, a los que AT&T agregó el ksh compatible con Bourne . Eventualmente, csh tenía un código fuente semidisponible, pero estaba involucrado 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 empresas sofisticadas que podían pagar la tarifa de $ 50,000 comprarían la licencia de AT&T pero instalarían las distribuciones BSD 4.x, y las universidades la obtendrían gratis.
  5. En esta situación con muchos problemas legales y técnicos, se llevaron a cabo varias implementaciones independientes. Al menos la misma cantidad se fue con el csh sintaxis como sucedió con la sintaxis de shell de Bourne, y algunos fusionaron las dos. Tenías al menos tcsh , zsh , bash y ash . La sintaxis de Bourne era "oficial", siendo parte de los lanzamientos de AT&T, pero en esos días BSD era bastante importante, y Sun, inicialmente BSD, distribuía una buena cantidad del software de Unix que encontraba el mundo.
  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 grande que ellos (el estado de California) y al final no ganaron la demanda, por lo que eventualmente la distribución de BSD estaba en un acuerdo legal 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 su autor original lo repudió en privado) y merece todo 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 superconjunto completo que reemplaza a posix-sh, incluso hasta el punto de que, si se llama como /bin/sh, emulará posix-sh por completo. Posix-sh era el "estándar" para los sistemas Unix comerciales como shell de denominador común. Entonces, algo que comienza ahí y se basa en eso es comenzar con mucho.

Linux
  1. Las 5 distribuciones de Linux más estables en 2022

  2. ¿Por qué el archivo de traducción de Bash no contiene todos los textos de error?

  3. Linux:¿por qué no funciona Setuid?

  4. Linux:¿por qué Apt Autoremove no elimina todos los paquetes antiguos del kernel a la vez?

  5. Una breve historia de las distribuciones de código abierto/Linux

Cómo usar el comando Declare en Linux Bash Shell

Cómo instalar Linux Bash Shell en Windows 10

Solución de problemas del error "Bash:Comando no encontrado" en Linux

¿Por qué Ctrl + V no se pega en Bash (shell de Linux)?

¿Por qué se instala Perl de forma predeterminada con la mayoría de las distribuciones de Linux?

¿Por qué borrar el historial de bash no es suficiente?