GNU bug report logs - #17087
cp -i/yes gets ignored

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#17087: closed (cp -i/yes gets ignored)
Date: Tue, 25 Mar 2014 11:12:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 25 Mar 2014 11:10:19 +0000
with message-id <5331641B.5080108 <at> draigBrady.com>
and subject line Re: bug#17087: cp -i/yes gets ignored
has caused the debbugs.gnu.org bug report #17087,
regarding cp -i/yes gets ignored
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
17087: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17087
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: karl <at> freefriends.org (Karl Berry)
To: bug-coreutils <at> gnu.org
Subject: cp -i/yes gets ignored
Date: Mon, 24 Mar 2014 16:17:33 GMT

I find it annoying that explicitly answering "y" to an interactive
prompt in cp can get ignored:

$ touch foo
$ chmod 444 foo
$ cp -i /etc/issue foo
cp: try to overwrite 'foo', overriding mode 0444 (r--r--r--)? y
cp: cannot create regular file 'foo': Permission denied

It seems to me, in terms of UI, that this is clearly at least as
"forceful" (I would say more so) than -f, which does do the overwrite.

Also, both mv -i and rm -i already perform their action on a readonly
file when told "y"es.  So simple consistency is another argument that cp
should do the same.

Jim told me once that this behavior is specified by POSIX.  Hardly
surprising.  Can we DTRT here by default and reserve the stupid behavior
for POSIXLY_CORRECT?

Curmudgeonly,
Karl

[Message part 3 (message/rfc822, inline)]

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17087-done <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Tue, 25 Mar 2014 11:10:19 +0000

On 03/25/2014 06:25 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> That code has been there "from the beginning" and I'm guessing it's
>> to prompt users to allow them to chmod the file in a separate terminal?
> 
> If we go back far enough (i.e., before commit 6bf3479 dated 2000-08-27), this message was output only if -f was also given.

Things have flipped around a bit. Originally no prompts were output at all with --force (which was incorrect).

> More recently we've seen similar complaints, e.g.: http://lists.gnu.org/archive/html/bug-coreutils/2007-03/msg00130.html

Ah thanks for linking that.

> At least the diagnostic wording could be improved so that users who are prompted don't get the false impression that the copy will succeed; POSIX clearly allows this.  I installed the attached patches (the second is just a code cleanup).  Perhaps that's enough.

Looks good.

It will need adjustment so that the second string is tagged for translation.
I'll apply the following:

diff --git a/src/copy.c b/src/copy.c
index 71813dc..68b4c5e 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1575,10 +1575,10 @@ overwrite_ok (struct cp_options const *x, char const *dst_name,
       strmode (dst_sb->st_mode, perms);
       perms[10] = '\0';
       fprintf (stderr,
-               _((x->unlink_dest_before_opening
-                  || x->unlink_dest_after_failed_open)
-                 ? "%s: replace %s, overriding mode %04lo (%s)? "
-                 : "%s: unwritable %s (mode %04lo, %s); try anyway? "),
+               (x->unlink_dest_before_opening
+                || x->unlink_dest_after_failed_open)
+               ? _("%s: replace %s, overriding mode %04lo (%s)? ")
+               : _("%s: unwritable %s (mode %04lo, %s); try anyway? "),
                program_name, quote (dst_name),
                (unsigned long int) (dst_sb->st_mode & CHMOD_MODE_BITS),
                &perms[1]);

Marking this bug as done.

thanks,
Pádraig.

Previous Next

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