fmt: stops at an unreadable file operand and says only 'read error' for a directory
Los mantenedores suelen responder en 1 día
@emirmrkaljevic ya está trabajando en esto.
Desde el 27/10/2026.
- #15923 de @emirmrkaljevic — abierto
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 78/100
Línea de trabajo
Empieza por process_file y uumain en la implementación de fmt, donde el issue indica que los errores de archivo se propagan fuera del bucle de operandos. Compara ese flujo con el comportamiento descrito de GNU: informar de cada operando ilegible, seguir procesando los archivos posteriores y devolver un estado de error al final. Reprodúcelo con los ejemplos fmt d a.txt y fmt missing a.txt del issue; se considera terminado cuando a.txt se formatea después de cualquiera de los dos errores y el error del directorio menciona d.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
fmt stops at the first file operand it can't read and never formats the files after it. GNU fmt reports the bad operand and goes on with the rest. For a directory operand uutils also prints a bare read error with no file name, where GNU says error reading 'dir': Is a directory.
Found with behave, comparing uutils fmt (main) with GNU coreutils 9.12.
$ mkdir d; printf 'one\ntwo\n' > a.txt
$ fmt d a.txt # GNU 9.12
fmt: error reading 'd': Is a directory
one two
$ echo $?
1
$ fmt d a.txt # uutils
fmt: read error
$ echo $?
1
$ fmt missing a.txt # GNU 9.12
fmt: cannot open 'missing' for reading: No such file or directory
one two
$ fmt missing a.txt # uutils
fmt: cannot open 'missing' for reading: No such file or directory
In uutils, process_file returns the open/metadata/directory error with ?, and uumain propagates it, so the loop over the files ends there. GNU's fmt_file prints the error, records the failure, and returns so main keeps going.
- Lenguaje dominante
- Rust
- Estrellas
- 24.3k
- Forks
- 2.1k
- Merge medio
- 1 d 21 h
- PR fusionados (30 d)
- 357
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de uutils/coreutils
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
B - high priority U - tr
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
U - df
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
U - mv
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
shuf: exhausted random source destroys the input during an in-place shufflePosiblemente ocupada @limadog9 la tomó hace 2 días. AbiertoU - shuf
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
Todos los issues de uutils/coreutils
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
FalkorDB/FalkorDB#3597 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
mozilla-services/syncstorage-rs#2715 ·
Los mantenedores suelen responder en 1 día