Windows 版 Coreutils

原文 ↗ Hacker News 讨论 ↗

“Windows 版 Coreutils” 概述

  • 通过一个 Rust/uutils 分支，将（大部分）GNU coreutils 原生移植到 Windows。
  • 目标是让在 Linux、macOS、WSL、容器和 Windows 之间切换更“无摩擦”，让许多现有脚本只需最少改动即可运行。
  • 据称该项目提供了约 75% 的工具；有些工具是有意省略或被改动的。

与 uutils、GNU coreutils 及许可的关系

  • 这是现有 Rust uutils coreutils 的一个分支，而不是对 GNU coreutils 的直接移植。
  • 有人认为这有些重复，因为 uutils 本来就支持 Windows，而差异主要是一些 Windows 特定修复，原本“可以上游提交”。
  • 有强烈批评认为，MIT 许可的 uutils 和这个分支使绕开 GPL 成为可能；一些人将其描述为对 GNU/GPL 的攻击，以及“EEE”式行为。
  • 也有人认为，MIT 许可只是尽到了它的职责，即最大化采用率。

Shell 冲突与行为

  • 若干命令与 CMD/PowerShell 内建命令冲突（dir、echo、sort、find 等）。
  • 行为取决于 shell、PATH 顺序以及 PowerShell 别名；用户抱怨这削弱了“即插即用”的目标。
  • 还有一些技巧，比如根据启发式在 DOS 和 GNU 版本之间分派 find/sort；有人觉得这很混乱，且解释不足。
  • 建议包括给命令加前缀（像 BSD/macOS 上的 g*），或提供一个专用环境，让这些工具优先出现在 PATH 中。

缺失 / 被降优先级的工具

  • 一些命令（例如 shred、uname）被省略或被淡化为“在 Windows 上没用”，但许多人对此表示不同意。
  • 其他人指出，显然有用的工具（dd、一个真正的 chown/chmod、更好的 ln 集成、uname）本应被优先考虑。
  • README 只列出了有冲突或被排除的命令，这引发了困惑；澄清后表示“没有列出的都已包含”。

与现有方案的比较

  • 许多人会问，为什么不直接使用：
    • Cygwin/MSYS2、带 Bash 的 Git for Windows、Windows 版 Busybox、WSL/WSL1，或者现有的 uutils。
  • 批评者认为这是一种半成品、由营销驱动的重复建设，又在 Windows 上增加了另一个细微不兼容的类 Unix 环境。

动机与 AI 角度

  • 有人猜测真正的驱动力是 AI 代理：LLM 更擅长 Unix 风格的 CLI，而不是 PowerShell/CMD，因此原生 coreutils 有助于“Windows 上的代理”。
  • 项目代表声称，主要目标是熟悉 macOS/Linux 的人类开发者；AI 收益只是副作用。

更广泛的 Windows UX 争论

  • 讨论又回到了反复出现的话题：CRLF 与 LF、反斜杠与斜杠、驱动器盘符、POSIX 兼容性、UTF-16，以及 PowerShell 的对象管道与 Unix 工具基于文本的差异。
  • 没有共识：一些人欢迎这些工具，认为它们能改善使用体验；另一些人则表示，他们仍然宁愿使用 Linux、WSL 或现有的 Unix 层。