The Bun Shell

原文 ↗ Hacker News 讨论 ↗

Bun 推出了一个与 JavaScript 集成的 shell，用 Zig 重新实现了 `rm`、`ls` 和 `cd` 等常用命令，以提供快速、跨平台的脚本能力，而不依赖系统 shell 或 coreutils。评论者认为它对 package.json 脚本和以 JS 为主的工作流很有价值，并将其与 zx、Execa 和 Deno 的 dax 等工具相比较，但也提出了对部分 POSIX/GNU 兼容性、抽象泄漏、安全隐患以及如此庞大表面积的长期维护负担的担忧。这场讨论还触及一个更大的问题：shell 语义是否应当在通用语言内部重建，还是更专注于基于库的抽象会是更干净的解决方案。

目的与设计

  • Bun Shell 提供了一个 $ 标签模板 API，可从 JavaScript/TypeScript 以及在 CLI 中运行类似 shell 的命令。
  • 它在 Bun 运行时内部用 Zig 重新实现了常见命令（cd、rm、ls、mv、which、pwd、glob、环境变量、管道、重定向），而不是委托给系统 shell。
  • 其目标是让 package.json 脚本和小型自动化任务更易用、跨平台，尤其是像 rm -rf 这类在 Windows 上会失败的命令。

与现有 JS Shell 工具的比较

  • 经常被拿来与 zx、execa、dax、bsx、shelljs 比较。
  • 关键区别在于：Bun 有自己的 shell 和内建命令，而大多数库仍然会调用 bash/PowerShell，因此会受到这些环境的可用性和性能特性影响。
  • 该 API 被认为与 zx 非常相似，Bun 的文档也明确把这些工具作为灵感来源。

兼容性与语义

  • 一些评论者担心它只是部分兼容、非 POSIX 行为，以及那种“诡异的熟悉感”语义：命令看起来像熟悉的 Unix 工具，但在参数、行为和边界情况上可能不同（文件名、编码、颜色、TTY、时间戳）。
  • 有人质疑它的目标究竟是 POSIX 兼容，还是严格匹配 GNU coreutils；答案并不明确，一些人认为这应当被记录为一项兼容性策略。
  • 还有人担心未来新增的内建命令会悄悄覆盖系统工具。

安全性与“Eval”疑虑

  • 有人把它比作 eval；也有人指出，标签模板把代码与数据分离，并自动转义插值变量，从而降低命令注入风险。
  • 怀疑者仍然预期会出现“模板化 vs. 插值”之类的错误，并指出在另一种语言里运行 shell 字符串，本身仍是一种有风险的抽象。

性能

  • Bun 通过把一切保留在同一个运行时中，避免了重复启动 shell；这吸引了那些见过 Node 的 child_process 在大量启动子进程时变慢的用户。
  • 关于 shell 启动开销是否真的显著存在争论；一些基准测试显示，很多系统上的 shell 启动时间都在亚毫秒级。

采用、范围与可持续性

  • 爱好者喜欢 Bun“就是在构建有用的东西”，并觉得 JS+shell 的结合很适合替代冗长的 bash 脚本。
  • 也有人对 Bun 同时在做很多事情（运行时、打包器、测试运行器、shell）且又有 VC 资金支持感到不安，质疑如此庞大表面积的长期维护能力。
  • 目前 Windows 支持仍是实验性的，这削弱了其当前的跨平台叙事，也让一些读者感到困惑。

替代方案与更大的图景

  • 文中提到了多种替代方案：shx、bsx、Nushell、Murex、Go/Python/Kotlin 脚本，以及各种“用 X 语言实现 shell”的项目。
  • 更广泛的争论在于：shell 脚本是否应被 JS、Python、Go、Kotlin 等更丰富的语言取代，还是应继续把 shells 和 coreutils 作为基础抽象层。