head: continue after per-file read error

[rossilor95]

Fixes #11846.

head now reports per-file read errors correctly and continues processing the remaining input files.

Previously, reading from files like /proc/self/mem could be reported as a standard output write error because io::copy mixed read and write failures into the same error path.

This change keeps read errors associated with the input file, while preserving stdout write error handling. In particular, stdout failures such as writing a named file to /dev/full are still reported as standard output errors instead of being wrapped as input file read errors.

Added a regression test matching GNU tests/head/head-write-error, ensuring head input > /dev/full reports a stdout write error instead of wrapping it as an input read error. Example:

# Before:
$ uutils-head input > /dev/full
head: error reading 'input': error writing 'standard output': No space left on device

# After:
$ uutils-head input > /dev/full
head: error writing 'standard output': No space left on device

[oech3]

Would you avoid same letter n?

[sylvestre]

and avoid one letter variable :)

[xtqqczze]

A single letter variable is idiomatic for a variable bound by a pattern, but the outer variable should be named something like bytes_read.

[rossilor95]

Hey folks, thank you for the review! I renamed the variable to bytes_read and removed the one letter inner variable (used map_err instead).

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/tail-n0f (fails in this run but passes in the 'main' branch)

[codspeed-hq]

Merging this PR will not alter performance

✅ 319 untouched benchmarks
⏩ 46 skipped benchmarks¹

---

_{Comparing rossilor95:head-continue-after-read-error (cedac04) with main (2a8ce67)²}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (f28d828) during the generation of this report, so 2a8ce67 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[rossilor95]

GNU testsuite comparison:

GNU test failed: tests/tail/pid-pipe. tests/tail/pid-pipe is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/retry (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/cut/cut-huge-range is now being skipped but was previously passing.
Skip an intermittent issue tests/pr/bounded-memory (was skipped on 'main', now failing)

I see this GNU test for pipe fails for other open PRs. I tried to have a look but I don't understand how it can be related to this change. WDYT?

[xtqqczze]

• GnuTests / Aggregate GNU test results (pull_request) failure tracked by GNU: tests/tail/pid-pipe intermittent failure #12325.

[oech3]

This has cost by 0-filling BUF_SIZE even n<BUF_SIZE.

[rossilor95]

You're right. Tried to do this in a different way.

I switched to BufRead::fill_buf / consume so we read straight from the input's existing buffer and skip the per-call BUF_SIZE zero-fill.

The TakeLines adapter was only needed to feed the old Read-based loop, so I removed it together with its three unit tests.

[xtqqczze]

• GnuTests / Aggregate GNU test results (pull_request) failure tracked by GNU: tests/timeout/timeout-group intermittent failure #12354.

[rossilor95]

I think the test_mkfifo failures are unrelated to this PR. Can someone confirm? I see the same failure in this PR too

[rossilor95]

@rossilor95 at this point, you might want to rebase...

Done!