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.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Robert Hill <hill-robert <at> hotmail.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: In coreutils 9.5, "cp" command does not honor "--interactive" option
Date: Sat, 11 May 2024 23:03:09 +0000

[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)]

Message #8 received at 70887 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Robert Hill <hill-robert <at> hotmail.com>, 70887 <at> debbugs.gnu.org
Subject: Re: bug#70887: In coreutils 9.5, "cp" command does not honor
 "--interactive" option
Date: Sun, 12 May 2024 12:49:26 +0100

[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)]

Message #11 received at 70887 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Robert Hill <hill-robert <at> hotmail.com>, 70887 <at> debbugs.gnu.org
Subject: Re: bug#70887: In coreutils 9.5, "cp" command does not honor
 "--interactive" option
Date: Sun, 12 May 2024 08:06:01 -0700

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?

Message #14 received at 70887 <at> debbugs.gnu.org (full text, mbox):

From: Robert Hill <hill-robert <at> hotmail.com>
To: Pádraig Brady <P <at> draigBrady.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
Date: Sun, 12 May 2024 15:25:14 +0000

[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)]

Message #17 received at 70887 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Robert Hill <hill-robert <at> hotmail.com>,
 70887 <at> debbugs.gnu.org
Subject: Re: bug#70887: In coreutils 9.5, "cp" command does not honor
 "--interactive" option
Date: Sun, 12 May 2024 21:31:56 +0100

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

Previous Next

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