On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:
I'm not sure reverting would be best. It would introduce more confusion, and would make coreutils incompatible with FreeBSD again.
Reverting makes more sense than the current situation. I do not understand why you seem to value FreeBSD compatibility more than compatibility with the vast majority of installed coreutils/linux
systems.
Yes, it's not a good place to be. Surely current coreutils is better than what Debian is doing.
You've introduced a silent incompatibility and I'm trying to find some way to make that clear. If upstream would provide a better solution I would certainly use it. I have despaired of there being such since your attitude thus far seems to be entirely dismissive of compatibility concerns.
Another possibility is to add a warning that is emitted only at the end of 'cp'. The warning would occur only if the exit code differs because of this cp -n business.
You'd only emit a notification of a change in behavior if some (potentially uncommon/rarely encountered) situation arises which would actually trigger breakage? So people can't prepare ahead of time and change their script to handle the necessary change in logic, they can only maybe figure out why something broke at 2am when the uncommon event occurred?
At the end of the day, -n is basically a useless option with unknowable semantics which should be avoided by everyone. In the past it was an option which wasn't portable between coreutils/linux and freebsd systems, and I guess you've "fixed" that (by making it an option everyone should avoid entirely), but let's be honest about how common that concern was.
