Coreutils para Windows

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

Resumen de “Coreutils para Windows”

  • Port nativo de Windows de (la mayor parte de) GNU coreutils mediante un fork de Rust/uutils.
  • Objetivo: hacer que el paso entre Linux, macOS, WSL, contenedores y Windows sea más “frictionless” para que muchos scripts existentes funcionen con cambios mínimos.
  • Se informa que el proyecto distribuye ~75% de las utilidades; algunas se omiten o alteran intencionalmente.

Relación con uutils, GNU coreutils y la licencia

  • Este es un fork del coreutils de uutils en Rust ya existente, no un port directo de GNU coreutils.
  • Algunos lo ven como redundante, ya que uutils ya soporta Windows y las diferencias son principalmente correcciones específicas de Windows que “podrían upstreamarse”.
  • Hay una crítica fuerte de que uutils con licencia MIT y este fork permiten eludir la GPL; algunos lo plantean como un ataque a GNU/GPL y un comportamiento al estilo “EEE”.
  • Otros argumentan que la licencia MIT está haciendo su trabajo al maximizar la adopción.

Conflictos del shell y comportamiento

  • Varios comandos entran en conflicto con las utilidades integradas de CMD/PowerShell (dir, echo, sort, find, etc.).
  • El comportamiento depende del shell, del orden de PATH y de los alias de PowerShell; los usuarios se quejan de que esto socava el objetivo de “drop-in”.
  • Hay trucos como alternar entre variantes DOS y GNU para find/sort basándose en heurísticas; a algunos les parece desordenado y poco explicado.
  • Se sugieren soluciones como prefijar comandos (como g* en BSD/macOS) o tener un entorno dedicado donde estas herramientas aparezcan primero en PATH.

Utilidades faltantes / despriorizadas

  • Algunos comandos (p. ej., shred, uname) se omiten o se restan importancia como “no útiles en Windows”, algo que muchos disputan.
  • Otros señalan que herramientas obviamente útiles (dd, un chown/chmod adecuado, mejores integraciones de ln, uname) deberían haberse priorizado.
  • Surgió confusión porque el README enumeraba solo los comandos en conflicto o excluidos; las aclaraciones dicen que “todo lo que no está listado está incluido”.

Comparación con opciones existentes

  • Muchos preguntan por qué no usar simplemente:
    • Cygwin/MSYS2, Git for Windows (con Bash), Busybox para Windows, WSL/WSL1 o el propio uutils existente.
  • Los críticos lo ven como una duplicación a medio cocinar y orientada al marketing, que añade otro entorno Unix-like sutilmente incompatible en Windows.

Motivaciones y ángulo de IA

  • Algunos especulan que el verdadero motor son los agentes de IA: los LLM se manejan mejor con CLI estilo Unix que con PowerShell/CMD, así que los coreutils nativos ayudarían a “agentes en Windows”.
  • Los representantes del proyecto afirman que el objetivo principal son los desarrolladores humanos familiarizados con macOS/Linux; los beneficios para IA serían un efecto secundario.

Debates más amplios sobre la UX de Windows

  • El hilo deriva en temas recurrentes: CRLF frente a LF, barras invertidas frente a barras, letras de unidad, compatibilidad POSIX, UTF-16 y el pipeline de objetos de PowerShell frente a las herramientas de texto de Unix.
  • No hay consenso: algunos reciben con agrado las herramientas como una mejora de calidad de vida; otros dicen que seguirían prefiriendo Linux, WSL o las capas Unix ya existentes.