Coreutils para Windows

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

El lanzamiento por parte de Microsoft de un conjunto nativo de utilidades básicas tipo GNU para Windows, construido sobre un fork de `uutils` basado en Rust, es bien recibido por muchos que quieren herramientas familiares al estilo Unix sin depender de WSL, Cygwin o Git Bash. Los comentaristas cuestionan decisiones de diseño como la cobertura parcial de comandos, los conflictos de nombres con las utilidades integradas de CMD/PowerShell y la decisión de esquivar la GPL construyendo sobre un proyecto con licencia MIT. Otros lo ven como parte de un impulso más amplio para hacer Windows más cómodo para desarrolladores de Linux/macOS y potencialmente más fácil para agentes de IA que asumen un entorno de línea de comandos parecido a POSIX.

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.