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

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 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: Tue, 30 Jan 2024 10:31:32 -0800

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

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.

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.

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

Previous Next

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