On 29/01/2024 14:01, Michael Stone wrote:
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.
That's a bit unfair. The current upstream -n behavior is with a view
to being _more_ compat across all systems.
Now I agree this may not be worth it in this case,
but it is a laudable goal.
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?
Yes I agree with this point, mostly.
Outputting a diagnostic would help users diagnose what's going on,
and help users to fix forward and avoid their problematic -n usage.
But yes, the crux of the issue with fixing issues as they occur,
is it depends on the state of the destination and so can become an issue
at any time. Now I previously did an audit with github and debian code search
and noticed very few problematic uses of cp -n, but that does miss
the mountain of private code.
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.
Right, that's why I'm still leaning towards my proposal in the last mail.
- revert to previous exit success -n behavior
- document -n as deprecated
- provide --update=noclobber to give exit failure functionality
- BTW, it probably makes sense to print a diagnostic for each skipped file
here
as it's exceptional behavior, for which we're exiting with failure for.
- the existing --update=none provides the exit success functionality
With the above in place for the next coreutils release,
then debian could remove its noisy patch.
thanks,
Pádraig
