GNU publica por qué rechaza las peticiones de funciones para coreutils

El proyecto GNU mantiene una página poco visitada donde recopila las peticiones de funcionalidad que ha rechazado para coreutils, con el motivo de cada descarte y un enlace al hilo de la lista de correo donde se discutió. No es un museo de ocurrencias: es el criterio de los responsables escrito negro sobre blanco, y sirve para saber qué opciones no van a existir por mucho que se sigan pidiendo.

El patrón se repite: si ya hay otra herramienta que lo resuelve, no se añade nada. cat --timestamp se cayó porque awk o perl lo cubren; cat --header, que imprimiría el nombre de cada fichero, porque tail -n+1 ya lo hace; y cat --show-ends para marcar espacios finales, también. Hasta cat -d para forzar E/S directa se descartó: dd trae las opciones direct y nocache, y para el resto de casos existe un envoltorio como nocache.

El argumento de "usa otra herramienta"

En chmod, la idea de mantener el ctime cuando los permisos no cambian se consideró un parche ineficiente. Las variantes para tocar solo directorios (chmod -d, chmod +S, chmod -D) se resolvieron con el modo X o con find combinado con chmod, y lo mismo ocurrió con chmod --parents o chmod --umask.

cp y mv acumulan rechazos parecidos. Para silenciar errores de fichero inexistente, basta con filtrar antes qué existe. Para reanudar, rsync. Para limitar el ancho de banda, rsync otra vez. Para copiar en paralelo, el arreglo corresponde a una capa más baja. Y --preserve=all para arrastrar atributos extendidos de ext2 exigiría una interfaz agnóstica del sistema de ficheros, algo del estilo de copyfile().

cut no tendrá soporte de CSV: se prefirió una utilidad aparte por lo enrevesado del formato. Tampoco habrá opción corta para --output-delimiter, ni reordenado de campos, ni separador de línea alternativo; con tr o awk se apaña quien lo necesite. En dd se descartaron limitar el caudal (mejor pv o trickle), que conv=noerror se aplicara también a las escrituras (para eso está shred) y conv=offload por demasiado especializado.

df y du tienen lo suyo: df -h se consideró suficiente para el escalado automático de unidades, las opciones de cabecera solo interesan a quien consume datos, y --dereference acabó cambiándose para seguir siempre el destino del enlace. En du, ordenar por uso de disco ya lo hace du -h | sort -h, y excluir directorios del recuento se resuelve con find.

En ls, la clasificación por tipo se filtra con ls --color -lF | sed, el orden por inodo es cosa de find | sort, y los permisos en octal salen de stat o find. Para separadores de millares, la respuesta oficial pasa por BLOCK_SIZE o numfmt.

Algunos de esos hilos tienen más de una década, así que la lista también funciona como archivo de decisiones antiguas que nadie ha reabierto. Para quien escribe scripts, saber que una opción no va a llegar evita esperas inútiles y empuja hacia la herramienta correcta. El criterio de fondo, que cada utilidad haga una cosa y la haga bien, tiene defensores y detractores, y no siempre convence a quien pide la funcionalidad; lo útil es que el motivo esté publicado y se pueda leer el debate completo antes de montar nada encima.