GNU bug report logs - #62572
cp --no-clobber behavior has changed

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Michael Stone <mstone <at> debian.org>
Cc: 1058752 <at> bugs.debian.org, Bernhard Voelker <mail <at> bernhard-voelker.de>, 62572 <at> debbugs.gnu.org
Subject: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed
Date: Wed, 31 Jan 2024 14:06:08 +0000

On 30/01/2024 18:31, Paul Eggert wrote:
> On 2024-01-30 03:18, Pádraig Brady wrote:
>> So we now have the proposed change as:
>>
>>     - revert -n to old silent success behavior
>>     - document -n as deprecated
>>     - Leave --update=none as is (will be synonymous with -n)
>>     - Provide --update=none-fail to diagnose and exit failure
> 
> Thanks, that's a better proposal, but I still see several opportunities
> for confusion.
> 
> If I understand things correctly, cp --update=none is not synonymous
> with the proposed (i.e., old-behavior) cp -n, because -n overrides
> previous -i options but --update=none does not. Also, -n overrides
> either previous or following --update=UPDATE options, but --update=none
> overrides only previous --update=UPDATE options. (For what it's worth,
> FreeBSD -n overrides

Good point.
Well -n is a protection mechanism really, so should override.
Since --update now incorporates a protection mode, it should also override I think.

> Some of this complication seems to be for consistency with how mv
> behaves with -f, -i, -n, and --update, and similarly with how rm behaves
> with -f, -i, -I, and --interactive. To be honest I don't quite
> understand the reason for all this complexity, which suggests it should
> be documented somewhere (the manual?) if it isn't already.

To my mind the most protective option takes precedence.
So from least to most that would be -f -n --update=none --update=none-fail -i
So the main consideration there is that -n should not override --update=none-fail

> This raises more questions:
> 
> * If we deprecate cp -n, what about mv -n? FreeBSD mv -n behaves like
> Coreutils mv -n: it silently does nothing and exits successfully. So
> there's no compatibility argument for changing mv -n's behavior.
> However, whatever --update option we add to cp (to output a diagnostic
> and exit with failure) should surely also be added to mv, to aid
> consistency.

Yes I agree.

> * Should cp --update=none be changed so that it really behaves like the
> old cp -n, in that it overrides other options in ways that differ from
> how the other --update=UPDATE options behave? I'm leaning toward "no" as
> this adds complexity that I don't see the use for.
> 
> * If we don't change cp --update=none's overriding behavior, is it still
> OK to tell users to substitute --update=none for -n even though the two
> options are not exactly equivalent? I'm leaning towards "yes" but would
> like other opinions.

Yes I think we should still give that advice to deprecate -n,
if we ensure that -n does not override --update=none=fail.

thanks,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.