Todo un mar de shell

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 en que Bourne escribió su shell. Y obviamente, cuando lo escribes en esas circunstancias, tienes que renunciar a muchas cosas. Bourne renunció a muchas cosas. Es increíble que haya incluido tantas cosas en el shell, dadas las limitaciones de espacio, memoria y CPU con las que trabajó.

Y acuérdate de que el Bourne shell todavía era parte del sistema UNIX de Bell Labs. Todavía estaba vinculado a la licencia UNIX. Es decir, no era gratuito. No era abierto. Este shell tenía dueños.

Era muy difícil obtener el código fuente de UNIX si no formabas parte de alguna universidad. Obviamente eso tuvo efecto en la popularidad del Berkeley UNIX, por ejemplo, que comenzó en una universidad, creció en una comunidad de universidades y de algún modo despegó por el camino más fácil, por así decirlo. Así que podías obtener acceso al código del Bourne shell si estabas en el lugar indicado, pero en general, no era viable.

Chet Ramey es el encargado del mantenimiento del Bash shell.

Así que estamos en los inicios de los shells, el comienzo de este componente fundamental para la programación, pero el mejor shell que hay está vinculado a una licencia. Es cerrado. Para la Free Software Foundation, esa situación estaba lejos de ser lo ideal. Lo que se necesitaba era un shell que no estuviera atado a ninguna empresa, un shell del pueblo.

Pero aquí está el detalle: había que escribir algo que tuviera todas las funciones del Bourne shell sin infringir ninguno de los molestos derechos de autor. Porque si copiabas el código textual del Bourne shell, te iban a demandar.

Para liberar a las personas del Bourne shell, había que encontrar un programador con la capacidad de escribir un programa así de complejo, un programa que hiciera lo mismo que el Bourne shell, pero sin ninguna parte del código fuente de Bourne. Había que encontrar un genio desconocido.

Brian Fox tenía veintitantos años, había dejado la preparatoria; y sabía más de código que la mayoría de la gente de Bell Labs. Nunca había estado en ninguna situación en que siquiera pudiera ver el código fuente que hacía funcionar el Bourne shell, así que era ideal para la tarea en cuestión.

Me llamo Brian Fox.

Pues sí, yo dije: “¿por qué no nos cuenta la historia el protagonista?”. En la actualidad, Fox es defensor del código abierto y director ejecutivo de Opus Logica. Pero a fines de la década de los ochenta, era simplemente un joven que creía en el movimiento del software libre. Hablamos sobre los viejos tiempos y sobre la evolución de Bash desde aquella época.

Entonces te pidieron que crearas un shell para UNIX. Que fuera un shell libre y que reemplazara al Bourne shell. ¿Cuál fue tu respuesta a esa solicitud?

“¿No podemos hacer uno mejor?”

Ay, me encanta.

Escuché que te tomó nueve meses desarrollarlo. ¿Fue difícil?

Lo difícil es que teníamos que imitar fielmente todos los comportamientos del Bourne shell, del shell original de Stephen Bourne, pero al mismo tiempo podíamos ampliarlo y hacer que fuera una mejor herramienta para las personas.

Y al mismo tiempo, yo estaba en una disputa discreta y secreta con David Korn, el autor del Korn shell. El comité de POSIX, que es el comité que dictamina cuál es el estándar para UNIX, se involucró y dijo: “Bueno, necesitamos definir el shell estándar”, y las dos personas más pertinentes para decidir eso éramos David Korn y yo. David Korn ya había escrito un shell llamado KSH, y decía que todas las características que había puesto en él deberían ser características estándar, ¿me explico? Para él lo más fácil es que simplemente fuera su shell, en lugar de tener que crear un shell POSIX perfecto.

Pero algunas de esas características no eran buenas, no eran buenas opciones y volvían al shell incompatible con el Bourne shell, o yo sentía que nos faltaban características, así que tuvimos varias discusiones y disputas al respecto. Al final construir un shell conforme a POSIX que fuera 100 % compatible con cada script de shell que se hubiera escrito para el Bourne shell llevó más de tres meses.

Pero entonces, si estabas diseñando algo que no solo reemplazaba el Bourne shell, sino que también intentaba imitar cada una de sus partes, me imagino que te encontraste con algunos problemas de derechos de autor. ¿Cómo los abordaste?

Para crear un verdadero software de código abierto y libre, tienes que hacerlo desde cero. No puedes ver el código de otra persona, empezar con él y reimplementarlo. Bueno, pues yo nunca había visto ningún software asociado con ningún sistema Bell, UNIX ni Berkeley UNIX, nunca había visto el código fuente de ninguno de ellos.

Cuando comencé a crear el Bash shell, usé un analizador llamado Bison, que era completamente distinto de cualquier otro programa anterior. Así que ya sabía que lo que estaba creando no iba a infringir los derechos de autor de nada que se hubiera creado anteriormente.

La encomienda de crear Bash tenía muchos contratiempos. Este es solo un ejemplo, para los héroes empedernidos que nos estén escuchando.

En algún momento, estaba trabajando en la implementación de globbing en el shell. Se trata de la expansión de comodines que te permite encontrar una gran cantidad de archivos, por ejemplo. Podías poner asterisco punto C, y con eso buscarías cada archivo que tuviera una extensión con punto C.

Bueno, pues trabajé en el globbing durante varias horas y logré que funcionara. Me entusiasmaba. Era una buena implementación. Y en el transcurso de la creación de esa implementación, había creado un archivo en mi directorio que se llamaba asterisco punto C, y pensé: “Bueno, ya no necesito ese archivo, voy a tirarlo”, y escribí: RM, espacio, comilla, asterisco punto C, comilla de cierre, y en un shell moderno, cuando usas las comillas, significa “No expandir esto”, y luego pulsé Intro, y el sistema se tardó mucho tiempo porque estábamos usando unas Sun 350 y todo era lento. Pero me di cuenta de que estaba tomando mucho tiempo porque estaba eliminando todos los archivos de origen en el directorio.

Ay, no.

Sí. Así que borré el código fuente de Bash en ese momento.

Ay, no.

Lo cual…

Ay, Dios, qué barbaridad.

Lo cual me hizo reír a carcajadas un buen rato. No me enojé ni nada. Y luego, durante los próximos días, volví a escribir todo. Tenía el código bien fresco en mi mente.

Vaya.

Los problemas se habían resuelto. Era solo cuestión de escribirlo en archivos.

Sí. La mayoría de la gente se volvería loca en ese momento. Tú te reíste y pensaste: “Ah, bueno, pues creo que tengo que volver a hacer todo”. ¿Por qué estabas tan tranquilo?

Es que me pareció completamente absurdo y muy gracioso que estaba construyendo la herramienta, y para estar seguro de que estuviera bien, la pruebo, o sea, para estar seguro de que la herramienta funciona correctamente la usas mientras la construyes, pero la herramienta no funcionó bien. Todavía no había implementado las comillas, y como no las había implementado, el comando que escribí de casualidad no hizo lo que yo quería que hiciera, y me dio mucha risa.

Qué increíble.

Pero incluso esa anécdota sobre un error habla de la agudeza mental de Fox. Dicen que Mozart terminó las sinfonías en la cabeza y luego solo tuvo que escribirlas cuando las había terminado. Fox tenía un talento similar.

Y cuando finalmente terminaste y pudiste entregar el Bash shell, ¿cómo te sentiste?

Ah, pues me sentí muy bien. Esto que te voy a decir no lo cuento seguido. Ya había estado alrededor de ocho meses construyendo el shell. Y yo sabía que necesitaba aproximadamente otro mes para terminar, y en eso lanzaron otro shell. El ASH. Lanzaron un shell de código abierto, y yo me puse muy triste porque todavía no habíamos enviado el Bash shell a nadie, así que solo unas pocas personas lo estaban usando. Yo sabía que necesitaba otro mes de trabajo y pensé: “Ay, qué barbaridad. Puse muchísima energía y esfuerzo, y nadie lo va a notar. Tal vez ni siquiera lo vean”. Estaba muy angustiado. No me hacía ninguna gracia.

Pero había que ponerlo a prueba para ver. Bash se lanzó en 1989 y se convirtió en el shell predeterminado para Linux. Hoy en día está presente en toda nuestra experiencia informática.

Pero está en todas partes. Muchas personas lo usan cada día. Está en cada computadora. ¿Qué se siente ser el autor de Bash?

La mayor parte del tiempo, ni siquiera me doy cuenta de que Bash es más que una herramienta que uso en mi vida diaria. Realmente ni siquiera lo pienso. Pero a veces entro a una tienda de Apple, veo a mi alrededor y pienso: “Guau, todas estas computadoras no solo se ejecutan con un software que escribí hace 27 años o más, sino que además llevan mi nombre”, y luego pienso: “Cada computadora conectada a Internet, cada servidor conectado a Internet está ejecutando el Bash shell y lleva mi nombre”. Y luego Windows hace unos años presentó el Power shell, que es Bash, y yo pensé: “Qué barbaridad. Mi nombre está en todas las computadoras del planeta”.

Quiero que escuchen muy bien lo que Fox me dijo después, porque es muy importante. Nunca intentó escribir un código para lograr la dominación del mundo. Estaba tratando de ayudar, tratando de ayudar a la cultura de la programación de la que formaba parte.

Mi objetivo para nada era estar en las computadoras de todo el mundo. Eso no me interesaba para nada. Yo quería crear un software útil y esperaba que tuviera la vida útil normal de un software de entre tres y cinco años, no estos 30 años que ha tenido.

¿Siempre fuiste tan, la verdad, tan poco pretencioso respecto al impacto que has tenido en la informática?

Bueno, estoy orgulloso de haber escrito el Bash y sí, tengo cierto ego, así que, por ejemplo, acepto hablar en podcasts sobre el shell.

Muchas gracias.

Gracias a ti. Pero no es algo que esté presente en mi vida cotidiana. Afortunadamente, soy simplemente un desconocido, ¿no? Porque mi software se ejecuta en las computadoras de todo el mundo, en las casas de todo el mundo, pero nadie lo sabe, ¿no? Vivo en el anonimato, pero el hecho de que el shell existe, de que alguien lo escribió y de que esa persona vive en Santa Bárbara, California se está haciendo más conocido cada vez, y yo cada vez lo noto más en mi vida. La gente a veces viene a verme tocar y luego me dicen: “Pero es que tú escribiste el shell”, y me siento como Keanu Reeves.

Maravilloso. Dijiste que tu objetivo no era que Bash estuviera en cada computadora. ¿Entonces qué querías lograr con Bash? ¿Cuál era el propósito?

Pues era una herramienta de reemplazo útil para formar parte del proyecto GNU y para ayudar a crear el sistema operativo de código abierto gratuito. En realidad yo pensé que cuando hubiéramos terminado de crear ese sistema operativo de código abierto, el software de ese sistema iba a avanzar y yo iba a tener la oportunidad de crear el tipo de shell que quería crear, para ayudar a la gente a avanzar en la ciencia, por así decirlo.

Pero luego me di cuenta de que el verdadero motivo por el que se había creado Bash era ser compatible con todo el mundo de UNIX que ya existía, y eso es lo que lo ha mantenido vivo, lo cual también es único: que tu herramienta sea tan importante, tan fundamental que no la puedan sacar de escena.

Absolutamente.

El saber que he creado algo de valor en el mundo, algo que otras personas siguen usando, ha sido realmente maravilloso. Y luego, cuando pienso en cómo surgió eso, me doy cuenta de que lo más importante es que las palabras “software libre” y “código abierto” estén en el lenguaje habitual, en el lenguaje cotidiano en todo el mundo, porque hubo un momento en que eso no era así. Y el ser parte de ese movimiento... Es bueno haber participado en los inicios, pero también es muy satisfactorio mirar hacia atrás y pensar: “¡Guau!, el software de código abierto existe, y yo fui parte de eso”.

Brian Fox es el creador del Bash shell y director ejecutivo de Opus Logica.

La verdad sí escuché hablar de Bash.

Ese era Steve Bourne, creador del Bourne shell, el que reemplazó Brian Fox. Queríamos saber qué pensaba Bourne sobre el trabajo de Fox. Qué pensaba de Bash, de esa réplica del Bourne shell, ese clon abierto de su propio trabajo. O sea, ¿no le molestaba Bash?

La persona que lo escribió se me acercó un día en una conferencia y me dio una camiseta que en el frente decía “Bourne again”, o sea, “Bourne renacido”.

Se refiere a Brian Fox.

Me la dio con una actitud amistosa, y me dijo: “Pues espero que no te moleste, pero acabo de reescribir tu shell”, y yo le dije: “¡Qué bien!”, y me dio una camiseta.

Si algo he aprendido del mundo de la programación, es que a todos les encantan los artículos promocionales. Resulta que para Steve Bourne, Bash era una extensión necesaria del trabajo que otras personas y él hacían en Bell Labs. No hay ni un ápice de resentimiento.

Había cosas que la gente quería hacer respecto a la sustitución de variables y la gestión de strings que yo no hacía, pero que estaban en Bash, 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.