Coreutils for Windows

Original Article ↗ Hacker News Discussion ↗

Overview of “Coreutils for Windows”

  • Native Windows port of (most of) GNU coreutils via a Rust/uutils fork.
  • Goal: make moving between Linux, macOS, WSL, containers, and Windows more “frictionless” so many existing scripts work with minimal changes.
  • Project reportedly ships ~75% of the utilities; some are intentionally omitted or altered.

Relation to uutils, GNU coreutils, and Licensing

  • This is a fork of the existing Rust uutils coreutils, not a direct GNU coreutils port.
  • Some see it as redundant since uutils already supports Windows and the differences are mainly Windows-specific fixes that “could be upstreamed.”
  • Strong criticism that MIT-licensed uutils and this fork enable bypassing the GPL; some frame it as an attack on GNU/GPL and “EEE”-style behavior.
  • Others argue MIT licensing is doing its job by maximizing adoption.

Shell Conflicts and Behavior

  • Several commands conflict with CMD/PowerShell built-ins (dir, echo, sort, find, etc.).
  • Behavior depends on the shell, PATH ordering, and PowerShell aliases; users complain this undermines the “drop-in” goal.
  • There are hacks like dispatching between DOS and GNU variants for find/sort based on heuristics; some find this messy and under-explained.
  • Suggestions include prefixing commands (like g* on BSD/macOS) or having a dedicated environment where these tools come first in PATH.

Missing / Deprioritized Utilities

  • Some commands (e.g., shred, uname) are omitted or de-emphasized as “not useful on Windows,” which many dispute.
  • Others note obviously useful tools (dd, a proper chown/chmod, better ln integrations, uname) should have been prioritized.
  • Confusion arose from the README listing only conflicted or excluded commands; clarifications say “everything not listed is included.”

Comparison to Existing Options

  • Many ask why not just use:
    • Cygwin/MSYS2, Git for Windows (with Bash), Busybox for Windows, WSL/WSL1, or existing uutils.
  • Critics see this as a half-baked, marketing-driven duplication that adds yet another subtly incompatible Unix-like environment on Windows.

Motivations and AI Angle

  • Some speculate the real driver is AI agents: LLMs are better at Unix-style CLI than PowerShell/CMD, so native coreutils helps “agents on Windows.”
  • Project representatives claim the primary aim is human developers familiar with macOS/Linux; AI benefits are a side effect.

Broader Windows UX Debates

  • Thread spirals into recurring themes: CRLF vs LF, backslashes vs slashes, drive letters, POSIX compatibility, UTF-16, and PowerShell’s object pipeline vs text-based Unix tools.
  • No consensus: some welcome the tools as a quality-of-life improvement; others say they’d still rather use Linux, WSL, or existing Unix layers.