The Bun Shell

Artículo original ↗ Discusión en Hacker News ↗

Bun ha introducido un shell integrado con JavaScript que reimplementa comandos comunes como `rm`, `ls` y `cd` en Zig para ofrecer scripts rápidos y multiplataforma sin depender del shell o de coreutils del sistema. Los comentaristas ven valor para scripts de package.json y flujos de trabajo centrados en JS, comparándolo con herramientas como zx, Execa y dax de Deno, pero plantean preocupaciones sobre compatibilidad parcial con POSIX/GNU, abstracciones con fugas, trampas de seguridad y la carga de mantenimiento a largo plazo de una superficie tan amplia. El debate aborda si las semánticas de shell deberían recrearse dentro de lenguajes de propósito general o si abstraerlas mediante bibliotecas más enfocadas sería una solución más limpia.

Propósito y diseño

  • Bun Shell expone una API de tagged-template con $ para ejecutar comandos al estilo de shell desde JavaScript/TypeScript y en la CLI.
  • Reimplementa comandos comunes (cd, rm, ls, mv, which, pwd, globbing, variables de entorno, pipes, redirección) en Zig dentro del runtime de Bun en lugar de delegarlos al shell del sistema.
  • Su objetivo es hacer que los scripts de package.json y las pequeñas tareas de automatización sean más cómodos y multiplataforma, especialmente cosas como rm -rf que fallan en Windows.

Comparación con herramientas de shell existentes en JS

  • A menudo se compara con zx, execa, dax, bsx, shelljs.
  • Diferenciador clave: Bun tiene su propio shell y built-ins, mientras que la mayoría de las bibliotecas siguen invocando bash/PowerShell y sufren sus particularidades de disponibilidad y rendimiento.
  • La API se considera muy similar a zx, y la documentación de Bun cita explícitamente esas herramientas como inspiración.

Compatibilidad y semántica

  • Varios comentaristas se preocupan por un comportamiento parcial, no POSIX, y una semántica de “valle inquietante”: los comandos se parecen a herramientas Unix familiares, pero pueden diferir en flags, comportamiento y casos extremos (nombres de archivo, codificaciones, colores, TTY, marcas de tiempo).
  • Hay dudas sobre si apunta a ser compatible con POSIX o una coincidencia estricta con GNU coreutils; la respuesta no está clara, y algunos argumentan que esto debería documentarse como una política de compatibilidad.
  • Existe preocupación por cambios futuros en los que nuevos built-ins podrían sobrescribir silenciosamente utilidades del sistema.

Seguridad y preocupaciones de “eval”

  • Algunos lo comparan con eval; otros señalan que las plantillas etiquetadas separan el código de los datos y escapan automáticamente las variables interpoladas, reduciendo los riesgos de inyección de comandos.
  • Los escépticos siguen esperando errores eventuales de “templating vs. interpolation” y señalan que ejecutar cadenas de shell dentro de otro lenguaje sigue siendo una abstracción arriesgada.

Rendimiento

  • Bun evita iniciar el shell repetidamente al mantener todo en un solo runtime; esto resulta atractivo para usuarios que han visto que child_process de Node se ralentiza bajo mucha creación de procesos.
  • Hay debate sobre si el coste de arranque del shell realmente es significativo; algunos benchmarks muestran que los shells arrancan en rangos de submilisegundos en muchos sistemas.

Adopción, alcance y sostenibilidad

  • A los entusiastas les gusta que Bun “simplemente construya cosas útiles” y encuentran atractiva la mezcla de JS + shell para reemplazar largos scripts bash.
  • A otros les inquieta que Bun intente muchas cosas (runtime, bundler, test runner, shell) mientras está financiado por VC, cuestionando el mantenimiento a largo plazo de una superficie tan amplia.
  • El soporte para Windows es actualmente experimental, lo que por ahora debilita la historia multiplataforma y confunde a algunos lectores.

Alternativas y panorama general

  • Se mencionan múltiples alternativas: shx, bsx, Nushell, Murex, scripting en Go/Python/Kotlin y varios proyectos de “shell pero en el lenguaje X”.
  • Debate más amplio: si el scripting de shell debería ser reemplazado por lenguajes más ricos (JS, Python, Go, Kotlin) o si los shells y coreutils deberían seguir siendo la capa de abstracción fundamental.