Man, if I had a nickel every time some old Linux utility ignored a command-line flag I'd have a lot of nickels. I'd have even more nickels if I got one each time some utility parsed command-line flags wrong.
I have automated a lot of things executing other utilities as a subprocess and it's absolutely crazy how many utilities handle CLI flags just seemingly correct, but not really.
This doesn't look like a bug, that is, something overlooked in the logic. This seems like a deliberately introduced regression. Accepting an option and ignoring it is a deliberate action, and not crashing with an error message when an unsupported option is passed must be a deliberate, and wrong, decision.
cataflam|4 months ago
The core bug seems to be that support for `date -r <file>` wasn't implemented at the time ubuntu integrated it [1, 2].
And the command silently accepted -r before and did nothing (!)
0: https://lwn.net/Articles/1043123/
1: https://github.com/uutils/coreutils/issues/8621
2: https://github.com/uutils/coreutils/pull/8630
Avamander|4 months ago
I have automated a lot of things executing other utilities as a subprocess and it's absolutely crazy how many utilities handle CLI flags just seemingly correct, but not really.
nine_k|4 months ago
pedrocr|4 months ago
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
janzer|4 months ago
The last commit[0] is a fix for date parsing to bring it in line with the GNU semantics, which seems like a pretty good candidate.
Edit: Or not, see evil-olive's comment[1] for a more likely candidate.
0: https://github.com/uutils/coreutils/commit/0047c7e66ffb57971...
1: https://news.ycombinator.com/item?id=45687743
egorfine|4 months ago