GNU bug report logs -
#70887
In coreutils 9.5, "cp" command does not honor "--interactive" option
Previous Next
To reply to this bug, email your comments to 70887 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#70887
; Package
coreutils
.
(Sun, 12 May 2024 01:03:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Robert Hill <hill-robert <at> hotmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Sun, 12 May 2024 01:03:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
After upgrading coreutils from 9.0 to 9.5, the following change occurred:
In coreutils 9.0, the command "cp -Tipruvx /src-dir /dst-dir" requested
interactive confirmation before replacing an old destination file with a
newer source file, as expected.
In coreutils 9.5, the command "cp -Tipruvx /src-dir /dst-dir" no longer
requests interactive confirmation, but just goes ahead and replaces old
destination files with newer source files, which is not expected.
Thank you in advance for looking at this, Bob.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#70887
; Package
coreutils
.
(Sun, 12 May 2024 11:51:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 70887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/05/2024 00:03, Robert Hill wrote:
> After upgrading coreutils from 9.0 to 9.5, the following change occurred:
>
> In coreutils 9.0, the command "cp -Tipruvx /src-dir /dst-dir" requested
> interactive confirmation before replacing an old destination file with a
> newer source file, as expected.
>
> In coreutils 9.5, the command "cp -Tipruvx /src-dir /dst-dir" no longer
> requests interactive confirmation, but just goes ahead and replaces old
> destination files with newer source files, which is not expected.
>
> Thank you in advance for looking at this, Bob.
Right.
The thinking was for 9.3 that the new long form --update={older,all} options
would override a previous -i, especially as -i was commonly set in root
users' cp and mv aliases on Red Hat flavored distros.
Then in 9.5 we expanded this so -u behaved the same as --update=older.
In retrospect, users can avoid these aliases in various ways,
and the protective -i option should really combine with -u
rather than being overridden by it.
For completeness, -i following -u would always reinstate the protection.
The attached changes the behavior back to that -i is never overridden.
thanks,
Pádraig
[cp-mv-i-u-prompt.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#70887
; Package
coreutils
.
(Sun, 12 May 2024 15:07:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 70887 <at> debbugs.gnu.org (full text, mbox):
On 2024-05-12 04:49, Pádraig Brady wrote:
> @@ -1151,7 +1151,8 @@ main (int argc, char **argv)
> {
> /* Default cp operation. */
> x.update = false;
> - x.interactive = I_UNSPECIFIED;
> + if (x.interactive != I_ASK_USER)
> + x.interactive = I_UNSPECIFIED;
> }
> else if (update_opt == UPDATE_NONE)
> {
> @@ -1166,7 +1167,8 @@ main (int argc, char **argv)
> else if (update_opt == UPDATE_OLDER)
> {
> x.update = true;
> - x.interactive = I_UNSPECIFIED;
> + if (x.interactive != I_ASK_USER)
> + x.interactive = I_UNSPECIFIED;
Thanks for looking into this messy area. Here is a comment from another
pair of eyes.
Could you elaborate a bit more about why these two bits of code change
x.interactive at all? That is, why doesn't update_opt simply affect
x.update? Why does update_opt bother to override a previous setting of
x.interactive to I_ALWAYS_YES, I_ALWAYS_NO, or I_ALWAYS_SKIP?
Another way to put it: shouldn't x.update simply reflect the value of
the --update option, whereas x.interactive reflects reflects whether -f,
-i, -n are used? Although this would require changes to copy.c, it'd
make the code easier to follow.
Another way to put it: why should, for example, --update=all override a
previous -f or (partly) -n but not a previous -i?
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#70887
; Package
coreutils
.
(Sun, 12 May 2024 15:26:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 70887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Pádraig, Thank you very much indeed for responding so quickly and thoroughly.
As you suggest, instead of "cp -Tipruvx ..." I am now using "cp -Tpruivx ..."
("-i" after "-u"), which works just fine. Many thanks, and kind regards, Bob.
________________________________
From: Pádraig Brady <pixelbeat <at> gmail.com> on behalf of Pádraig Brady <P <at> draigBrady.com>
Sent: Sunday, May 12, 2024 11:49
To: Robert Hill <hill-robert <at> hotmail.com>; 70887 <at> debbugs.gnu.org <70887 <at> debbugs.gnu.org>
Subject: Re: bug#70887: In coreutils 9.5, "cp" command does not honor "--interactive" option
On 12/05/2024 00:03, Robert Hill wrote:
> After upgrading coreutils from 9.0 to 9.5, the following change occurred:
>
> In coreutils 9.0, the command "cp -Tipruvx /src-dir /dst-dir" requested
> interactive confirmation before replacing an old destination file with a
> newer source file, as expected.
>
> In coreutils 9.5, the command "cp -Tipruvx /src-dir /dst-dir" no longer
> requests interactive confirmation, but just goes ahead and replaces old
> destination files with newer source files, which is not expected.
>
> Thank you in advance for looking at this, Bob.
Right.
The thinking was for 9.3 that the new long form --update={older,all} options
would override a previous -i, especially as -i was commonly set in root
users' cp and mv aliases on Red Hat flavored distros.
Then in 9.5 we expanded this so -u behaved the same as --update=older.
In retrospect, users can avoid these aliases in various ways,
and the protective -i option should really combine with -u
rather than being overridden by it.
For completeness, -i following -u would always reinstate the protection.
The attached changes the behavior back to that -i is never overridden.
thanks,
Pádraig
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#70887
; Package
coreutils
.
(Sun, 12 May 2024 20:34:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 70887 <at> debbugs.gnu.org (full text, mbox):
On 12/05/2024 16:06, Paul Eggert wrote:
> On 2024-05-12 04:49, Pádraig Brady wrote:
>
>> @@ -1151,7 +1151,8 @@ main (int argc, char **argv)
>> {
>> /* Default cp operation. */
>> x.update = false;
>> - x.interactive = I_UNSPECIFIED;
>> + if (x.interactive != I_ASK_USER)
>> + x.interactive = I_UNSPECIFIED;
>> }
>> else if (update_opt == UPDATE_NONE)
>> {
>> @@ -1166,7 +1167,8 @@ main (int argc, char **argv)
>> else if (update_opt == UPDATE_OLDER)
>> {
>> x.update = true;
>> - x.interactive = I_UNSPECIFIED;
>> + if (x.interactive != I_ASK_USER)
>> + x.interactive = I_UNSPECIFIED;
>
> Thanks for looking into this messy area. Here is a comment from another
> pair of eyes.
>
> Could you elaborate a bit more about why these two bits of code change
> x.interactive at all? That is, why doesn't update_opt simply affect
> x.update? Why does update_opt bother to override a previous setting of
> x.interactive to I_ALWAYS_YES, I_ALWAYS_NO, or I_ALWAYS_SKIP?
>
> Another way to put it: shouldn't x.update simply reflect the value of
> the --update option, whereas x.interactive reflects reflects whether -f,
> -i, -n are used? Although this would require changes to copy.c, it'd
> make the code easier to follow.
I agree that some refactoring would be good here.
At least x.update should be renamed to x.update_older.
As interactive selection, and file dates all relate
to selecting which files to update, it's tempting to conflate the settings.
However you're right that this introduces complexities when
trying to avoid all inconsistencies. Currently for example:
$ cp -v -i --update=none new old # Won't prompt as expected
$ cp -v --update=none -i new old # Unexpectedly ignores update option
So yes we should separate these things.
> Another way to put it: why should, for example, --update=all override a
> previous -f or (partly) -n but not a previous -i?
Right -f is significant for mv here (for completeness -f for cp is a separate thing).
I.e. we need to treat I_ALWAYS_YES specially in mv with the current scheme.
BTW -n is not overridden by any --update option currently,
and this change effectively applies the same logic to -i now.
thanks,
Pádraig
This bug report was last modified 195 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.