On 2023-12-15 10:49, Michael Stone wrote:
There's no compelling reason to force this change
Well, certainly nobody compelled us at gunpoint....
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.) It seemed
like a good idea at the time all things considered, and to my mind still
does.
Essentially the current situation is that -n shouldn't be used if you expect a
certain behavior for this case and you are writing a script for linux systems.
Maybe in 10 years you'll be able to assume the new behavior. Better to just
tell people to not use it at all, and leave the historic behavior alone until
everyone has stopped using -n entirely.
Even if we tell people not to use -n at all, that doesn't mean we should
revert to the coreutils 9.1 behavior.
The cat is to some extent out of the bag. Unless one insists on (FreeBSD
| coreutils 9.2-9.4), or insist on coreutils 7.1-9.1, one should not
rely on cp -n failing or silently succeeding when the destination
already exists. This will remain true regardless of whether coreutils
reverts to its 7.1-9.1 behavior.
