yes: use splice_data functions from uucore

[DaringCuteSeal]

Have yes use the splice-write utilities from uucore. Follow-up of #6964.

[sylvestre]

Suggested change

use std::fs::File;

[sylvestre]

Suggested change

	use nix::{errno::Errno, libc::S_IFIFO, sys::stat::fstat};
	use nix::{libc::S_IFIFO, sys::stat::fstat};

[DaringCuteSeal]

eh, i figured out some missing compile guards on the buf-copy. lemme resolve em first and make a new PR

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/misc/yes. tests/misc/yes is passing on 'main'. Maybe you have to rebase?
Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/misc/yes. tests/misc/yes is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/misc/yes. tests/misc/yes is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)

[cakebaker]

Did you see that some jobs in the CI fail?

[DaringCuteSeal]

Did you see that some jobs in the CI fail?

oh, hmm i didn't see those. sorry, i'll try to fix em a bit later

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/misc/yes. tests/misc/yes is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)

[DaringCuteSeal]

Hi, ran into a problem here. >,<

I found out that yes actually needs to know the kind of error that the write function encountered, and if it is returning from a broken pipe, yes will return without any error which I think makes sense. I suspect this is why the tests on Windows are problematic.

The problem is that, yes cannot know the kind of error it gets as the functions it uses (from the buf-copy module I made for a refactor in #6964) because the functions all return a UResult (just a trait).

I'm actually considering deleting altogether the code I separated from yes in uucore, as I think the use case for those functions is pretty specific to yes anyways.

So, what do the devs here think? There are two choices I see:

• Make several functions from buf-copy return std::io::Error. Not too elegant imo
• Do not modify yes as its use of buffer-copying is too specific to be split into a module. Delete the functions I split from uucore/buf-copy.

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/misc/yes. tests/misc/yes is passing on 'main'. Maybe you have to rebase?

[sylvestre]

Do not modify yes as its use of buffer-copying is too specific to be split into a module. Delete the functions I split from uucore/buf-copy.

Let's do that, it is fine :)