Re:Swapping GNU coreutils for uutils coreutils on Gentoo Linux
by photonbeam on Thursday June 20, 2024 @12:46AM
(#40735008)
It’s somewhat inevitable that something will try to replace the C implementation of coreutils.
Hopefully uutils will fix whichever bugs are reported upstream to lower the compatibility load though
Re:Swapping GNU coreutils for uutils coreutils on Gentoo Linux
by initplus on Thursday June 20, 2024 @01:03AM
(#40735087)
At least it's somewhat possible to reliably test behavior of these against GNU coreutils. Pull down some archaic C++ project with a pile of janky shell scripts involved in the build (Chromium might be a good target) and compare final results.
Re:Swapping GNU coreutils for uutils coreutils on Gentoo Linux
by yjftsjthsd-h on Thursday June 20, 2024 @01:34AM
(#40735261)
One could argue that building Gentoo is an excellent way to exercise things:) Which, granted, is kinda cheating since you could just `emerge chromium` or whatever... but IMHO even just making portage itself happy is a good first step.
Re:Swapping GNU coreutils for uutils coreutils on Gentoo Linux
by lionkor on Thursday June 20, 2024 @01:29AM
(#40735229)
Why? Are you unhappy with the IMO very good test coverage, or has it not been working well for you the past checks notes decades?
Re:Swapping GNU coreutils for uutils coreutils on Gentoo Linux
by tadfisher on Thursday June 20, 2024 @01:33AM
(#40735253)
Author didn't state a preference either way, but why do you care? Nothing is wrong with a reimplementation, as using it will nail down any untested/undocumented behavior of the original code.
Re:Swapping GNU coreutils for uutils coreutils on Gentoo Linux
by pixelbeat on Thursday June 20, 2024 @11:52AM
(#40740124)
Sounds like a case of:
https://www.pixelbeat.org/programming/sigpipe_handling.html
uutils uses the coreutils test suite, so it makes sense to add a test case for that, which uutils will eventually get to. I'll do that now.
I'm a fish-shell developer and I just dealt with a user that was getting bizarre test failures. Turns out the developers didn't account for basic things like the normalcy of `cat` having its output fd closed mid-stream (e.g. you are piping cat to something and that something exits before cat does) and their vesrion bails with an exception dumped to stderr instead of silently closing with a non-zero exit code.