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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 29, 2024 at 04:11:05PM +0000, Pádraig Brady wrote:

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.

You are saying that again without explicitly acknowledging that "being
_more_ compat" in this case means "becoming _incompat_ with the vast
majority of installed systems". IMO it could be reasonably phrased as
"being more compatible across all systems in the long term when all
existing legacy systems are gone", but the key here is that I read
"_more_ compat across all systems" as dismissing the coreutils installed
base as part of "all systems". I understand that may not be/have been
the intent, but I also can't help feeling the way that I do when the
benefits of compatability with freebsd are repeatedly emphasized while
the costs of incompatibility with the coreutils installed base are
dismissed with something along the lines of "we'll see what breaks". (If
the costs of incompatibility are really that low in this case, why would compatability be a worthwhile goal in this case?)

I do wish that more users had noticed the change earlier and that we're
fairly deep into a mess, but it's not always easy to see the impact of
what seems like a relatively minor patch. I do appreciate that the new
version printed some diagnostics when the change was triggered, as that certainly helped call attention to scripts which were impacted.

With the above in place for the next coreutils release,
then debian could remove its noisy patch.

I would certainly align with that, and the sooner the better to decrease
the chances that different distributions handle this in different ways
or we get to the point of having to release in an interim state. If you
commit a final version I'll apply that patch if the next release isn't imminent.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/29/24 08:11, Pádraig Brady wrote:

Right, that's why I'm still leaning towards my proposal in the last mail.

Well, I won't insist on doing nothing; however, the proposal needs
ironing out and now's a good time to do it before installing changes.

  - revert to previous exit success -n behavior
  - document -n as deprecated
  - provide --update=noclobber to give exit failure functionality

So --update=noclobber would differ in meaning from the deprecated-in-9.5 --no-clobber, but would agree in meaning with 9.4 --no-clobber? That
sounds pretty confusing for future users. (And a nit: why should one
spelling have a hyphen but the other doesn't?)

    - 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.

Coreutils 9.4 cp -n already does that, no? So I'm not sure what's being proposed here.

$ touch a b
$ cp -n a b; echo $?
cp: not replacing 'b'
1

  - the existing --update=none provides the exit success functionality

It seems to me that this proposal conflates two questions:

* What rules should cp use to decide whether to update a destination?

* When cp decides not to update a destination, what should it do? Exit
with nonzero status? Output a diagnostic? Both? Neither?

Aren't these independent axes? If so, shouldn't they have independent
options? For example, since we have --update=older, shouldn't there be a
way to say "I want to copy A to B only if B is older than A, and I want
the exit status to be zero only if A was copied to B"?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)