fmt: stops at an unreadable file operand and says only 'read error' for a directory
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start with process_file and uumain in the fmt implementation, where the issue says file errors propagate out of the operand loop. Compare that flow with GNU's described behavior: report each unreadable operand, keep processing later files, and return a failing status overall. Reproduce with the issue's fmt d a.txt and fmt missing a.txt examples; done means a.txt is formatted after either error and the directory error names d.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Rust
- Stars
- 24.3k
- Forks
- 2.1k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 357
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from uutils/coreutils
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
B - high priority U - tr
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
U - df
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
U - mv
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
shuf: exhausted random source destroys the input during an in-place shufflePossibly taken @limadog9 claimed this 1 day ago. OpenU - shuf
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
All issues in uutils/coreutils
Similar issues
-
needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
mozilla-services/syncstorage-rs#2715 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 82/100
physicsdolphin/nv-uefi-unlocker#53 · 4 reactions ·
Maintainers usually reply within 1 day