Show logo

Todo un mar de shell

  |  Command Line Heroes Team   Desarrollo y distribución de aplicaciones. Historia de la tecnología

Command Line Heroes • • Command Line Heroes: tercera temporada: Todo un mar de shell

Command Line Heroes: tercera temporada: Todo un mar de shell

About the episode

La TI a gran escala es posible gracias a los shells. Actualmente son un elemento necesario en la informática, pero probablemente no habría sido así sin el arduo trabajo de uno de los desarrolladores de la Free Software Foundation llamado Brian Fox. Ahora, el Bash shell se encuentra en casi todas las computadoras del mundo. En los años 70, Bell Labs quería automatizar las secuencias de comandos complejos y repetitivos. Chet Ramey nos cuenta que la empresa desarrolló varios shells, pero solo uno sería oficialmente compatible con UNIX. ¡Y en eso llegó el Bourne shell! Era el mejor de la cosecha, pero tenía sus límites y solo estaba disponible con una licencia UNIX limitada. Brian J. Fox relata su tiempo en la Free Software Foundation, en que necesitaba crear una versión libre del Bourne shell. Tenía que ser compatible, pero sin utilizar ningún elemento del código fuente original. Tal vez ese Bourne-Again Shell, también conocido como Bash, sea el software más utilizado del mundo. Taz Brown señala que es una de las herramientas más importantes para un desarrollador.

Command Line Heroes Team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

Estamos en 1987. Los Estados Unidos de Ronald Reagan están en pleno apogeo, y un muchacho de 27 años que dejó la preparatoria tiene grandes sueños y va de camino a su nuevo hogar en Santa Bárbara. Se llama Brian Fox, y en el maletero de su auto trae dos cintas enormes con el código que él mismo escribió. Lleva muchos años trabajando como programador en una corriente conocida como el movimiento del software libre. Para él, el código que trae en el maletero forma parte de una nueva realidad, un nuevo paradigma del software al que su comunidad está dando vida poco a poco. En ese año, un equipo de programadores de la Free Software Foundation intentaba liberar el mundo de la programación. Querían crear una alternativa al sistema operativo UNIX, que había dominado la programación desde los setenta. Entonces crearon GNU, cuyas siglas significaban GNU no es UNIX, y su objetivo era que fuera un sistema operativo que todo el mundo pudiera usar sin preocuparse por las tarifas de licencia o los derechos de autor. La fundación había estado elaborando aquel atrevido sistema operativo durante años. ¿Y las dos cintas enormes de código que viajaban en el maletero de Brian Fox? Ah, pues guardaban un componente fundamental. En esas cintas, había escrito un shell libre y abierto que completaría el sistema operativo GNU: el obsequio de Brian Fox para el movimiento del software libre. Lo llamó Bash. Esto es Command Line Heroes en español, un podcast original de Red Hat. En este episodio vamos a ver la manera en que nuestros héroes crearon el shell Bash. Descubriremos la historia de los shells y veremos por qué son tan importantes para nuestro trabajo hoy en día. Para entender qué son los scripts de shell, imagínate el guion de un actor. Es una secuencia completa de comandos que el shell luego ejecuta solo, como un actor que lee sus líneas una tras otra. Son la mejor solución si tienes comandos repetitivos o intrincados. Son la clave de la automatización. Se podría decir que los scripts de shell impulsan nuestro desarrollo. ¿Pero podía escribirse un shell que le diera ese superpoder a todo el mundo? Ese era el desafío. En 1969, un par de investigadores informáticos de aquí de Bell Labs empezaron a desarrollar unos programas que necesitaban para sus propios fines. Escuchamos a Ken Thompson, precursor y héroe de la línea de comandos. El sistema operativo UNIX, que se elaboró en Bell Labs, se había diseñado para su uso personal. Originalmente era solo un sistema interno. UNIX fomentaba la comunicación estrecha entre los programadores, pero no estaba diseñado para cambiar la forma en que funcionaba el mundo entero. Estaba diseñado para cambiar Bell Labs. Actualmente se utiliza en todo Bell Labs. Tenemos cerca de 20 mil terminales de computadora en esta empresa, y la mayoría se utiliza para comunicarse con los sistemas UNIX. En 1971 se lanzó un shell de UNIX diseñado por Ken Thompson. El Thompson shell estaba diseñado para ser intérprete de la línea de comandos, pero en realidad no podía interpretar scripts completos. No fue hasta seis años después, en 1977, que la programación con scripts comenzó a despegar. Los parámetros del shell, los parámetros especiales, las variables que hoy en día damos por sentado, se originaron con Steve Bourne y el Bourne shell. Escuchamos a Chet Ramey, arquitecto de TI en la Case Western Reserve University. Chet trabaja en el mantenimiento de Bash, y nos va a ayudar mucho a entender la historia de sus orígenes. Describe a Bell Labs justo en el momento en que estaba descubriendo qué sería el shell de UNIX. Los constructos de programación que usamos hoy en día sin pensarlo dos veces se originaron con Steve Bourne, y su shell básicamente ganó la competencia. Había una importante comunidad de usuarios que utilizaba el Mashey shell. Y había una importante comunidad de usuarios que comenzaba a usar el Bourne shell. Se estableció un comité para decidir qué shell ganaría, qué shell de UNIX se utilizaría oficialmente en Bell Labs de allí en adelante, y ganó el Bourne shell. Y como dicen, el resto es historia. ¡Pero no es el fin de la historia! Claro, el Bourne shell fue un gran salto hacia adelante. Nos abrió la puerta hacia las operaciones superpotentes y hacia una mayor automatización, pero aunque tuvo una especie de supremacía por un tiempo, el Bourne shell no resolvió todas nuestras necesidades de programación con scripts. Actualmente no nos podemos ni imaginar las limitaciones que tenía el Bourne shell original. No podías editar las líneas de comando, y si te equivocabas en algo, tenías que comenzar de cero. No había un historial de comandos. No podías usar las flechas para navegar. No había autocompletado con tabuladores. No había expansión de llaves. No había arreglos. No había funciones que tuvieran variables locales. Un montón de cosas que hoy damos por sentado, simplemente no existían. Chet Ramey es arquitecto de TI en la Case Western Reserve University y encargado del mantenimiento del Bash shell. Tenía muchas limitaciones, pero el Bourne shell fue el shell dominante desde finales de los setenta. Sin embargo, a medida que la programación con scripts se volvía más popular, surgía un problema cada vez más grande: las restricciones de las licencias. Para usar el Bourne shell, tenías que tener una licencia de UNIX. Era software propietario, y eso le ponía límites a lo que las personas podían hacer. Los programadores que creían en el software libre veían que necesitaban una alternativa. Necesitaban un shell que tuviera las ventajas del Bourne shell, pero que fuera libre. Entró en escena Brian J. Fox. Me llamo Brian J. Fox, y creé el shell Bash para la Free Software Foundation. En 1988, Brian trabajaba en la Free Software Foundation cuando lo encomendaron a crear un shell libre y compatible con Bourne. Llegué a la Free Software Foundation en 1986, y mi primera tarea fue escribir un shell que fuera compatible con el Bourne shell, pero que no contuviera ningún código de UNIX. Era un proyecto de sala limpia, lo que significa que no podía mirar el código fuente de UNIX del Bourne shell. Un proyecto de sala limpia significa escribir software completamente desde cero, sin mirar el código existente que ya hace lo que tú quieres hacer. Es asegurarse de que no violas ningún derecho de autor. Así que solo tenía la documentación, y tenía que crear un shell que se comportara exactamente igual. Tenía que leer todas las páginas del manual y asegurarme de que si alguien escribía un script de shell para el Bourne shell, funcionara igual de bien en mi shell. ¿Te imaginas la complejidad de esa tarea? Tenía que adivinar cómo funcionaba el Bourne shell internamente, solo leyendo su documentación. Brian pasó un año trabajando en esto. Fue un proyecto muy difícil. El Bourne shell tenía muchas peculiaridades y comportamientos no documentados que tenía que descubrir por prueba y error. Pero era emocionante trabajar en algo que sabía que iba a liberar la programación con scripts para todo el mundo. ¿Y por qué lo llamaste Bash? Bash significa "Bourne-again shell", o sea, el Bourne shell renacido. Era un juego de palabras con "born again", que significa nacer de nuevo en inglés. Queríamos capturar la idea de que estábamos tomando lo mejor del Bourne shell y dándole nueva vida como software libre. El primer lanzamiento de Bash fue en 1989. Pero ese fue solo el principio. Bash no solo recreaba las funciones del Bourne shell, sino que las mejoró. Una vez que tuvimos la compatibilidad básica con el Bourne shell, pudimos empezar a agregar características que la gente realmente quería. Agregamos edición de línea de comandos, historial de comandos, autocompletado con tabuladores, arreglos, muchas cosas que hacían que el shell fuera mucho más agradable de usar. Esas características que agregó Brian son las que ahora damos por sentado cuando usamos cualquier shell moderno. El autocompletado con tabuladores, por ejemplo, revolucionó la forma en que interactuamos con la línea de comandos. Sí, el autocompletado fue una de las características más populares. La gente ya no tenía que escribir nombres largos de archivos completos. Podían escribir las primeras letras y presionar tab, y el shell completaba el resto. Parece algo simple, pero ahorró una cantidad increíble de tiempo. ¿Había alguna característica específica de la que te sintieras especialmente orgulloso? La edición de línea de comandos era muy importante para mí. En el Bourne shell original, si cometías un error al escribir un comando largo, tenías que empezar de nuevo. Con Bash, podías usar las flechas para navegar, podías editar partes específicas del comando. Eso hizo que usar la línea de comandos fuera mucho menos frustrante. ¿Qué tan difícil fue hacer que Bash fuera realmente compatible con el Bourne shell? Era extremadamente difícil porque había muchos comportamientos no documentados del Bourne shell que la gente dependía de ellos. Tenía que hacer ingeniería inversa de todos estos casos especiales solo observando cómo se comportaba el shell original. ¿Tuviste que hacer algún compromiso en el diseño? El mayor compromiso fue mantener toda esa compatibilidad hacia atrás. Había características del Bourne shell que no eran muy elegantes, pero tenía que mantenerlas para que los scripts existentes siguieran funcionando. Eso a veces hacía que el código fuera más complicado de lo que me hubiera gustado. Pero esa compatibilidad hacia atrás fue crucial para el éxito de Bash, ¿no? Absolutamente. Si la gente no hubiera podido usar sus scripts existentes con Bash, nunca habría tenido éxito. La compatibilidad era lo más importante. ¿Cómo era trabajar en la Free Software Foundation en esos días? Era increíble. Estábamos construyendo algo completamente nuevo: un sistema operativo completamente libre. Richard Stallman tenía esta visión increíble de un mundo donde todo el software fuera libre, y nosotros estábamos haciendo que esa visión se volviera realidad, pieza por pieza. ¿Qué papel jugaba Bash en esa visión más grande? El shell era fundamental. Es la interfaz principal entre el usuario y el sistema operativo. Sin un shell libre y potente, GNU no habría sido viable para la mayoría de los usuarios. Bash era la pieza que conectaba todo. ¿Anticipaste que Bash se volvería tan popular como se volvió? Honestamente, no. Sabía que era importante para GNU, pero no tenía idea de que se volvería el shell estándar para tantos sistemas. El hecho de que ahora esté en prácticamente todas las computadoras del mundo es algo que nunca me imaginé. ¿Cuál crees que fue el factor clave para el éxito de Bash? Creo que fue la combinación de compatibilidad y características nuevas. La gente podía migrar fácilmente desde el Bourne shell, pero al mismo tiempo obtenían todas estas características nuevas que hacían su trabajo más fácil. Y, por supuesto, el hecho de que fuera libre. ¿Hay alguna característica de Bash moderno que te sorprenda? Las expresiones regulares integradas me parecen geniales. Y los arreglos asociativos que se agregaron en versiones posteriores son muy potentes. Bash ha evolucionado mucho más allá de lo que yo escribí originalmente. ¿Te sorprende que Bash siga siendo tan relevante después de más de 30 años? En cierto modo sí, porque la tecnología evoluciona tan rápido. Pero por otro lado, los conceptos fundamentales de la automatización y la programación con scripts siguen siendo los mismos. Bash resuelve problemas reales que la gente tiene todos los días. ¿Qué consejo le darías a alguien que está aprendiendo Bash por primera vez? Empezar con cosas simples. Aprende los comandos básicos primero, luego gradualmente ve agregando complejidad. Y practica escribiendo scripts para automatizar tareas que haces regularmente. Esa es la mejor manera de aprender. ¿Algún error común que veas que comete la gente? No entender el manejo de espacios en los nombres de archivos. Eso causa muchos problemas. También, no usar comillas donde deben usarlas. Esos son errores muy comunes que pueden causar comportamientos inesperados. ¿Qué piensas del futuro de Bash? Creo que va a seguir siendo relevante mientras la gente necesite automatizar tareas en sistemas Unix-like. Los shells más modernos como fish y zsh tienen características interesantes, pero Bash tiene la ventaja de estar en todas partes. ¿Hay alguna característica que te gustaría ver en futuras versiones de Bash? Mejor manejo de Unicode sería genial. Y tal vez algunas características más modernas para trabajar con JSON o APIs web. Pero siempre manteniendo esa compatibilidad hacia atrás. Hablando de compatibilidad, ¿alguna vez has considerado crear un "Bash 2.0" completamente nuevo? He pensado en eso, pero el valor de Bash está precisamente en esa compatibilidad. Si crearas algo completamente nuevo, perdería una de sus grandes ventajas. Mejor es evolucionar gradualmente. ¿Qué tan importante fue el timing del lanzamiento de Bash? Fue perfecto. GNU estaba ganando tracción, Linux estaba empezando a aparecer, y la gente necesitaba alternativas libres al software propietario. Bash llegó justo en el momento correcto. ¿Cómo cambió tu vida el éxito de Bash? Me dio mucha satisfacción saber que había contribuido algo duradero al mundo del software libre. Pero también era solo el comienzo de mi carrera. Después de Bash, seguí trabajando en otros proyectos. ¿Cuál fue tu siguiente proyecto después de Bash? Trabajé en el editor de texto Info para GNU, y después en varios proyectos comerciales. Pero Bash siempre tendrá un lugar especial para mí porque fue mi primera contribución realmente importante al software libre. ¿Alguna vez has tenido algún momento de "no puedo creer que hice esto"? Sí, especialmente cuando veo que Microsoft incluyó Bash en Windows. Nunca me imaginé que vería el día en que Microsoft abrazaría herramientas de código abierto de esa manera. ¿Qué opinas de esa integración de Bash en Windows? Es genial. Muestra cómo el software libre ha ganado. Ya no es una guerra entre sistemas operativos propietarios y libres. Es más sobre dar a los usuarios las mejores herramientas, sin importar de dónde vengan. ¿Hay algo de lo que te arrepientas en el diseño original de Bash? Tal vez podría haber sido más agresivo en limpiar algunas de las peculiaridades del Bourne shell original. Pero en ese momento, la compatibilidad era lo más importante, así que probablemente tomé las decisiones correctas. ¿Cómo era el proceso de desarrollo en esos días sin internet? Era mucho más lento. Tenía que enviar diskettes por correo para compartir código. Y para probar la compatibilidad, tenía que conseguir acceso a diferentes sistemas UNIX, lo cual no siempre era fácil. ¿Cómo obtenías feedback de los usuarios? Principalmente a través de grupos de noticias de Usenet y listas de correo. La comunidad de software libre era mucho más pequeña en esos días, pero también más unida. La gente realmente se ayudaba entre sí. ¿Qué fue lo más desafiante de crear Bash? Definitivamente fue hacer la ingeniería inversa del comportamiento del Bourne shell sin poder ver su código. Había tantos casos especiales y comportamientos no documentados que tenía que descubrir. ¿Hubo algún momento en que pensaste en abandonar el proyecto? Hubo momentos frustrantes, especialmente cuando me encontraba con comportamientos del Bourne shell que no tenían sentido. Pero nunca pensé seriamente en abandonar. Sabía que era demasiado importante. ¿Cómo celebraste cuando lanzaste la primera versión? Honestamente, no recuerdo una celebración específica. En esos días, era normal lanzar software y seguir trabajando en la siguiente versión. No había tanta fanfara como ahora. ¿Qué piensas cuando ves que Bash sigue siendo mantenido por Chet Ramey después de todos estos años? Me da mucha alegría. Chet ha hecho un trabajo increíble manteniendo y mejorando Bash. Es exactamente lo que yo esperaba que pasara con el software libre: que la comunidad se haría cargo y lo haría mejor. ¿Alguna vez hablas con Chet sobre el futuro de Bash? De vez en cuando. Es interesante ver cómo él piensa sobre los desafíos actuales. El mantenimiento a largo plazo de software libre es un problema fascinante. ¿Qué lecciones de Bash se aplicarían a crear software libre hoy? La compatibilidad sigue siendo crucial. Y documentar todo muy bien. Pero ahora también es importante tener una comunidad fuerte desde el principio, no solo esperar a que aparezca. ¿Hay algún proyecto de software libre actual que te emocione? Los proyectos de inteligencia artificial abierta me parecen muy prometedores. Y todo el ecosistema alrededor de contenedores y orquestación está resolviendo problemas reales de una manera muy elegante. Para cerrar, ¿cuál dirías que es el legado más importante de Bash? Haber democratizado la automatización. Bash puso herramientas poderosas de automatización en las manos de cualquiera que quisiera aprenderlas, sin barreras de licencias o costos. Brian J. Fox es el creador del Bash shell y director ejecutivo de Opus Logica. Pero esta historia no acaba con Brian Fox. Después de que él entregó las riendas de Bash, otro héroe de la línea de comandos tomó el control: Chet Ramey, quien hasta el día de hoy mantiene y mejora Bash. Steve Bourne, el creador del Bourne shell original, todavía está por ahí, y es interesante escuchar su perspectiva sobre cómo Bash ha evolucionado. Claramente Bash se ha convertido en algo más importante de lo que yo pensé que llegaría a ser. Tiene muchas más características que el shell original, y hay muchas más funciones incluidas de análisis de cadenas y funciones integradas y que se usan mucho en estos días. En ese momento yo sentía que la relación entre Bash y el shell original era que se trataba simplemente de una reimplementación del lenguaje y, con el tiempo le fueron agregando características, así que de algún modo progresó más allá de lo que yo escribí, por lo menos en el área de la gestión de strings. Yo lo uso todo el tiempo. Steve Bourne es el creador del Bourne shell y es director de tecnología en Rally Ventures. Han pasado muchos años desde que Brian Fox guardó el Bash en su maletero durante aquel largo viaje a Santa Bárbara. En 2019, se lanzó la versión 5.0, y como mencionó Fox, Bash ahora está integrado a Linux, a Mac OS e incluso a Microsoft Windows. A medida que UNIX dio paso a Linux, Bash se ha convertido en uno de los pilares de la programación con scripts, en el mundo del código abierto. Es fundamental para la automatización. A medida que las empresas crecían, era indispensable encontrar algo que nos permitiera agilizar las cosas. Se volvió una necesidad fundamental. Taz Brown es consultora sénior de Ansible Automation en Red Hat, así que conoce bien el valor de Bash. Sí, definitivamente, yo creo que alguien que está empezando su carrera debe usar Bash, en lugar de usar la interfaz gráfica de usuario. Te van a tomar más en serio si eres administrador o si estás en DevOps. Y eso se debe a que un programador de Bash tiene una de las habilidades fundamentales que simplemente te da ventaja. Claro, el valor de aprender a programar con scripts es que te prepara para pensar a largo plazo respecto a la automatización en sí, porque puedes ver cómo se ejecuta un script, para que puedas pensar: "Ah, pues sí, ya sé lo que voy a hacer. Esta tarea la voy a automatizar. Y esta también", y entonces cambia tu manera de pensar, cambias como tecnólogo. En las operaciones, la automatización se ha vuelto indispensable. Los programas, las aplicaciones y las herramientas sofisticadas dependen del código Bash heredado. No necesitas reinventar la rueda, por así decirlo. Puedes continuar y simplemente extraerlos de un repositorio de GitHub o de donde almacenes esos archivos en particular. Con Bash puedes hacer eso. Y también te permite tomar esas tareas comunes y escalarlas, digamos, de 10 servidores a 1000 servidores. Y lo bueno de la automatización es que, ya que tienes el plan para implementarla, te permite hacerlo de una manera muy eficiente en cuanto al costo. Puedes hacer cosas que no podrías hacer manualmente. Además, las novedades más recientes, como Ansible®, en la que trabaja Taz Brown, pueden integrarse con Bash. Las cosas han evolucionado, pero yo no creo que los administradores vayan a dejar de usar Bash, sobre todo si lo que quieres es una automatización rápida. Al final, todo el éxito de Bash se remonta al hecho de que es un programa libre y abierto. El deseo de Brian Fox de darle al mundo un shell sin licencias, sin ataduras, ha sido la clave de su éxito. De hecho, Brian Fox ya ni siquiera está a cargo. Desde hace mucho tiempo, de hecho. Otra vez vamos a escuchar a Chet Ramey, que ha sido el que le ha dado mantenimiento a Bash desde hace varias décadas. Después del lanzamiento de la versión 1.05, creo, Brian quería seguir adelante y trabajar en otras cosas. Le habían asignado otras tareas en la Free Software Foundation y no quería dedicarse solo a Bash, y yo era el colaborador más activo. Trabajamos juntos en muchas características nuevas, en muchas correcciones de errores y, cuando llegó el momento de que otra persona se hiciera cargo, pues yo era el candidato lógico. Ramey también va a necesitar relevos, igual que Fox, porque Bash es muy grande para un solo encargado de mantenimiento. Yo empecé cuando tenía 23 años, y Bash y yo hemos crecido juntos. En algún momento voy a tener que pedir un equipo. Voy a tener que buscar personas que estén dispuestas y tengan la capacidad necesaria para dedicarle tiempo al shell y hacerlo avanzar. Bash, que por cierto significa Bourne-again shell, o el Bourne shell renacido, ya cumplió 30 años y no muestra señales de que vaya a desaparecer. Bash se sumó a la ola del software libre, y luego a la ola del código abierto, hasta extenderse a cada rincón del mundo de la programación. Pero es increíble recordar que, en algún momento, solo era un código que estaba dentro de una cinta guardada en el maletero del auto de Brian Fox. Solo era el sueño de un lenguaje de shell que algunos programadores comprometidos querían regalarle al mundo. Casi por accidente, Brian Fox se convirtió en uno de los grandes héroes de la línea de comandos. Por cierto, hay algo que me da mucha curiosidad: ¿para qué se llevaba todo el código Bash a Santa Bárbara? ¿Para qué se iba a mudar? ¿Había encontrado trabajo en alguna empresa de tecnología, o…? Quería seguir mi carrera musical, y pensé que el mejor lugar para lograrlo era donde la temperatura siempre fuera de 22 grados, el cielo estuviera despejado y las playas fueran hermosas. Qué bien. Ese motivo me gusta más. En el próximo episodio llevaremos nuestro interés por la automatización a otro nivel y analizaremos los lenguajes de la inteligencia artificial, con un enfoque especial en LISP, la creación de John McCarthy. Command Line Heroes en español es un podcast original de Red Hat. Hasta la próxima, sigan programando.

More about historia de la tecnología

Para imaginar el futuro, es importante mirar al pasado y descubrir historias de innovación que asombren e inspiren.

Publicación en blog

Adopta un enfoque de detección temprana de fallos para desarrollar la automatización de la actualización de RHEL

13 de diciembre de 2025
  |  
Bob Mader
Automation and management
Publicación en blog

Ahora Red Hat Insights es Red Hat Lightspeed: gestión más rápida basada en la inteligencia artificial

13 de diciembre de 2025
  |  
Brent Midwood
Automation and management
Podcast original

Command Line Heroes: Cuarta temporada: Una cosa más con Steve Wozniak

Historia de la tecnología
Podcast original

Command Line Heroes: Cuarta temporada: Hardware open source: la alianza de los fabricantes

Open source, Historia de la tecnología
Podcast original

Command Line Heroes: Cuarta temporada: Teléfonos más inteligentes: las aventuras de la computadora de mano.

Historia de la tecnología

Sobre el podcast

Command Line Heroes

During its run from 2018 to 2022, Command Line Heroes shared the epic true stories of developers, programmers, hackers, geeks, and open source rebels, and how they revolutionized the technology landscape. Relive our journey through tech history, and use #CommandLinePod to share your favorite episodes.