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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17087 in the body.
You can then email your comments to 17087 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

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 #8 received at 17087 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 17087 <at> debbugs.gnu.org
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Mon, 24 Mar 2014 23:55:01 +0000

On 03/24/2014 04:17 PM, Karl Berry wrote:
> 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

I see the apparent redundancy here, though I think it is required.

-i prompts whether to overwrite any destination no matter what the mode.

Now one might be wondering of the futility of distinguishing the
non writeable case, prompting whether to "try to overwrite" the non writeable file.
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?

Are there other cases where open(O_WRONLY,...) might succeed?
If so then it would be incorrect to conflate a 'y' answer here with -f.
Even if open(O_WRONLY) would not on the current system if could be
dangerous to do generally.

thanks,
Pádraig.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Karl Berry <karl <at> freefriends.org>
Cc: 17087 <at> debbugs.gnu.org
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Mon, 24 Mar 2014 23:25:48 -0700

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

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

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.

[0001-cp-improve-quality-of-overwrite-prompt.patch (text/plain, attachment)]

[0002-cp-simplify-overwrite-logic.patch (text/plain, attachment)]

Message #16 received at 17087-done <at> debbugs.gnu.org (full text, mbox):

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.

Message #19 received at 17087-done <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: P <at> draigBrady.com
Cc: eggert <at> cs.ucla.edu, 17087-done <at> debbugs.gnu.org
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Tue, 25 Mar 2014 20:53:21 GMT

Well, I concur that the new wording is an improvement in that it reduces
expectations, but is it really so impractical to get the behavior that
is actually to be desired?  I expect the sources are much too advanced
for it to be something like "force++;" after getting the "y" response :),
but maybe ... something ... ?

The current behavior is noticeably frustrating, because it seems so
unnecessarily stupid.

    http://lists.gnu.org/archive/html/bug-coreutils/2007-03/msg00130.html

Thus, I also agree with that person's frustration in the other
direction, although for me it is the situation that I complained about
that comes up far more often -- unnecessarily failing to overwrite
writable files, rather than unnecessarily asking about unwritable files.

But I'm not volunteering to write a patch, and I know the logic in this
area is a maze of twisty little passages, some alike and some different,
so ...

thanks,
k

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady
 <P <at> draigBrady.com>, Karl Berry <karl <at> freefriends.org>
Cc: 17087 <at> debbugs.gnu.org
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Wed, 26 Mar 2014 14:26:43 +0100

On 03/25/2014 07:25 AM, Paul Eggert wrote:
> (the second is just a code cleanup).

Oops, that 2nd patch
  http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=7f669b40
now produces the following check failure:

FAIL: tests/mv/i-3
==================

++ initial_cwd_=/home/berny/coreutils
++ fail=0
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /home/berny/coreutils gt-i-3.sh.XXXX
+++ case $# in
+++ destdir_=/home/berny/coreutils
+++ template_=gt-i-3.sh.XXXX
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ case $template_ in
++++ unset TMPDIR
+++ d=/home/berny/coreutils/gt-i-3.sh.gj66
+++ case $d in
+++ test -d /home/berny/coreutils/gt-i-3.sh.gj66
++++ ls -dgo /home/berny/coreutils/gt-i-3.sh.gj66
++++ tr S -
+++ perms='drwx------ 2 4096 Mar 26 14:13 /home/berny/coreutils/gt-i-3.sh.gj66'
+++ case $perms in
+++ test 0 = 0
+++ echo /home/berny/coreutils/gt-i-3.sh.gj66
+++ return
++ test_dir_=/home/berny/coreutils/gt-i-3.sh.gj66
++ cd /home/berny/coreutils/gt-i-3.sh.gj66
++ gl_init_sh_nl_='
'
++ IFS=' 	
'
++ for sig_ in 1 2 3 13 15
+++ expr 1 + 128
++ eval 'trap '\''Exit 129'\'' 1'
+++ trap 'Exit 129' 1
++ for sig_ in 1 2 3 13 15
+++ expr 2 + 128
++ eval 'trap '\''Exit 130'\'' 2'
+++ trap 'Exit 130' 2
++ for sig_ in 1 2 3 13 15
+++ expr 3 + 128
++ eval 'trap '\''Exit 131'\'' 3'
+++ trap 'Exit 131' 3
++ for sig_ in 1 2 3 13 15
+++ expr 13 + 128
++ eval 'trap '\''Exit 141'\'' 13'
+++ trap 'Exit 141' 13
++ for sig_ in 1 2 3 13 15
+++ expr 15 + 128
++ eval 'trap '\''Exit 143'\'' 15'
+++ trap 'Exit 143' 15
++ trap remove_tmp_ 0
+ path_prepend_ ./src
+ test 1 '!=' 0
+ path_dir_=./src
+ case $path_dir_ in
+ abs_path_dir_=/home/berny/coreutils/./src
+ case $abs_path_dir_ in
+ PATH=/home/berny/coreutils/./src:/home/berny/coreutils/src:/home/berny/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/sbin:/usr/sbin
+ create_exe_shims_ /home/berny/coreutils/./src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ mv
+ test yes = yes
+ local i
+ for i in '$*'
+ env mv --version
mv (GNU coreutils) 8.22.45-137a42
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Parker, David MacKenzie, and Jim Meyering.
+ require_controlling_input_terminal_
+ tty -s
+ test -t 0
+ test '' = no
+ skip_if_root_
+ uid_is_privileged_
++ id -u
+ my_uid=717
+ case $my_uid in
+ return 1
+ trap '' TTIN
++ uname -s
+ test Linux = FreeBSD
+ touch f g h i
+ chmod 0 g i
+ ls /dev/stdin
++ readlink -f /dev/stdin
+ tty=/dev/pts/1
+ test -r /dev/pts/1
+ pid=18300
+ mv f g
+ retry_delay_ check_overwrite_prompt .1 7
+ local test_func=check_overwrite_prompt
+ local init_delay=.1
+ local max_n_tries=7
+ shift 3
+ local attempt=1
+ local num_sleeps=1
+ local time_fail
+ test 1 -le 7
++ gawk -v n=1 -v s=.1 'BEGIN { print s * n }'
+ local delay=0.1
+ check_overwrite_prompt 0.1
+ local delay=0.1
+ case "$(cat out)" in
++ cat out
+ sleep 0.1
+ return 1
+ time_fail=1
++ expr 1 + 1
+ attempt=2
++ expr 1 '*' 2
+ num_sleeps=2
+ test 2 -le 7
++ gawk -v n=2 -v s=.1 'BEGIN { print s * n }'
+ local delay=0.2
+ check_overwrite_prompt 0.2
+ local delay=0.2
+ case "$(cat out)" in
++ cat out
+ sleep 0.2
+ return 1
+ time_fail=1
++ expr 2 + 1
+ attempt=3
++ expr 2 '*' 2
+ num_sleeps=4
+ test 3 -le 7
++ gawk -v n=4 -v s=.1 'BEGIN { print s * n }'
+ local delay=0.4
+ check_overwrite_prompt 0.4
+ local delay=0.4
+ case "$(cat out)" in
++ cat out
+ sleep 0.4
+ return 1
+ time_fail=1
++ expr 3 + 1
+ attempt=4
++ expr 4 '*' 2
+ num_sleeps=8
+ test 4 -le 7
++ gawk -v n=8 -v s=.1 'BEGIN { print s * n }'
+ local delay=0.8
+ check_overwrite_prompt 0.8
+ local delay=0.8
+ case "$(cat out)" in
++ cat out
+ sleep 0.8
+ return 1
+ time_fail=1
++ expr 4 + 1
+ attempt=5
++ expr 8 '*' 2
+ num_sleeps=16
+ test 5 -le 7
++ gawk -v n=16 -v s=.1 'BEGIN { print s * n }'
+ local delay=1.6
+ check_overwrite_prompt 1.6
+ local delay=1.6
+ case "$(cat out)" in
++ cat out
+ sleep 1.6
+ return 1
+ time_fail=1
++ expr 5 + 1
+ attempt=6
++ expr 16 '*' 2
+ num_sleeps=32
+ test 6 -le 7
++ gawk -v n=32 -v s=.1 'BEGIN { print s * n }'
+ local delay=3.2
+ check_overwrite_prompt 3.2
+ local delay=3.2
+ case "$(cat out)" in
++ cat out
+ sleep 3.2
+ return 1
+ time_fail=1
++ expr 6 + 1
+ attempt=7
++ expr 32 '*' 2
+ num_sleeps=64
+ test 7 -le 7
++ gawk -v n=64 -v s=.1 'BEGIN { print s * n }'
+ local delay=6.4
+ check_overwrite_prompt 6.4
+ local delay=6.4
+ case "$(cat out)" in
++ cat out
+ sleep 6.4
+ return 1
+ time_fail=1
++ expr 7 + 1
+ attempt=8
++ expr 64 '*' 2
+ num_sleeps=128
+ test 8 -le 7
+ test 1 = 0
+ fail=1
+ kill 18300
+ mv -f h i
+ test -f i
+ test -f h
+ case "$(cat out)" in
++ cat out
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ remove_tmp_
+ __st=1
+ cleanup_
+ :
+ cd /home/berny/coreutils
+ chmod -R u+rwx /home/berny/coreutils/gt-i-3.sh.gj66
+ rm -rf /home/berny/coreutils/gt-i-3.sh.gj66
+ exit 1


BTW: in check_overwrite_prompt, the file 'out' contains
  "mv: unwritable 'g' (mode 0000, ---------); try anyway?"

Have a nice day,
Berny

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17087 <at> debbugs.gnu.org,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Wed, 26 Mar 2014 14:20:13 +0000

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

On 03/26/2014 01:26 PM, Bernhard Voelker wrote:
> On 03/25/2014 07:25 AM, Paul Eggert wrote:
>> (the second is just a code cleanup).
> 
> Oops, that 2nd patch
>   http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=7f669b40
> now produces the following check failure:
> 
> FAIL: tests/mv/i-3
> ==================

That's an interesting one. I guess our CI didn't flag this
as the test is skipped without a controlling tty:
http://hydra.nixos.org/jobset/gnu/coreutils-master

Also the test is skipped with a parallel make check!
I.E. this first command detects the fail, while the second skips the test:
  $ make -j2 check TESTS="tests/mv/i-3.sh"
  $ make -j2 check TESTS="tests/mv/i-2.sh tests/mv/i-3.sh"

So to handle both cases I'm updating the "release tasks" list to:
  setsid make check $(($(nproc) * 2)) # tests without controlling tty
  make check -j1 # tests with controlling tty

> BTW: in check_overwrite_prompt, the file 'out' contains
>   "mv: unwritable 'g' (mode 0000, ---------); try anyway?"

That should have been apparent in the test log immediately,
without you having to add debug.

In general we should allow these patches a little
while for review before pushing.

Hopefully the attached fixes up these issues.

thanks,
Pádraig.

[mv-prompt-fix.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 17087 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Wed, 26 Mar 2014 08:29:58 -0700

Pádraig Brady wrote:
> In general we should allow these patches a little
> while for review before pushing.

Perhaps I was a bit enthusiastic here, but still, I don't know, when in 
doubt I prefer an Emacs-like approach (push early and often and fix as 
soon as you can) to a glibc-like approach (everything needs review and 
lots of problems just don't get fixed).  If coreutils had used the glibc 
approach, I wouldn't have bothered to improve cp's diagnostics here, as 
it would have been too much trouble.  Even now, the maintenance 
procedures of coreutils are enough of a pain, and the code is enough of 
a tangle, that nobody is following up on Karl's eminently reasonable 
suggestions to improve cp's behavior in this area.

> Hopefully the attached fixes up these issues.

Thanks, I pushed it for you.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Bernhard Voelker <mail <at> bernhard-voelker.de>, 17087 <at> debbugs.gnu.org,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Wed, 26 Mar 2014 16:45:35 +0000

On 03/26/2014 03:29 PM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> In general we should allow these patches a little
>> while for review before pushing.
> 
> Perhaps I was a bit enthusiastic here, but still, I don't know, when in doubt I prefer an Emacs-like approach (push early and often and fix as soon as you can) to a glibc-like approach (everything needs review and lots of problems just don't get fixed).

I'm not suggesting everything _needs_ review.
I'm just suggesting we might take advantage of review.
I.E. we're posting the patches to the list anyway,
so just hold off on the submission until a review happens
or a few hours pass.  git branching makes this trivial to manage,
and so there should be no extra process.

Ideally more than one person should be looking at the code anyway,
and if that happens in a timely enough fashion to be in the
commit feedback loop that's even better.

> the maintenance procedures of coreutils are enough of a pain

Are you referring to GNU coding style,
commit message summary format or something else?
Is there anything we could make more lightweight here?

> and the code is enough of a tangle, that nobody is following up on Karl's eminently reasonable suggestions to improve cp's behavior in this area.

So I responded with 2 reasons why we might not make 'y' imply '-f' for unwritable files.
I'll think some more about what can be done here, but for me at least
code complexity it never a reason for not doing something.
The code here isn't that complex, it's the external implications
that are confusing and hard to consider (and thus best tracked in tests).

thanks,
Pádraig.

p.s. I use this git alias to sort branches by date:
  brdate = for-each-ref --sort=-committerdate --format='%(committerdate:iso8601) %(refname:short)' refs/heads/

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17087 <at> debbugs.gnu.org,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Thu, 27 Mar 2014 08:13:31 +0100

On 03/26/2014 03:20 PM, Pádraig Brady wrote:
> On 03/26/2014 01:26 PM, Bernhard Voelker wrote:
>> FAIL: tests/mv/i-3
>> ==================
> 
> That's an interesting one. I guess our CI didn't flag this
> as the test is skipped without a controlling tty:
> http://hydra.nixos.org/jobset/gnu/coreutils-master
> 
> Also the test is skipped with a parallel make check!
> I.E. this first command detects the fail, while the second skips the test:
>   $ make -j2 check TESTS="tests/mv/i-3.sh"
>   $ make -j2 check TESTS="tests/mv/i-2.sh tests/mv/i-3.sh"
> 
> So to handle both cases I'm updating the "release tasks" list to:
>   setsid make check $(($(nproc) * 2)) # tests without controlling tty
>   make check -j1 # tests with controlling tty

Thanks.
What about a ---presume-input-tty option for mv(1) like rm(1) has?

> Hopefully the attached fixes up these issues.

Yes, thanks!

Have a nice day,
Berny

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 17087 <at> debbugs.gnu.org
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Thu, 27 Mar 2014 12:46:34 +0000

On 03/27/2014 07:13 AM, Bernhard Voelker wrote:
> On 03/26/2014 03:20 PM, Pádraig Brady wrote:
>> On 03/26/2014 01:26 PM, Bernhard Voelker wrote:
>>> FAIL: tests/mv/i-3
>>> ==================
>>
>> That's an interesting one. I guess our CI didn't flag this
>> as the test is skipped without a controlling tty:
>> http://hydra.nixos.org/jobset/gnu/coreutils-master
>>
>> Also the test is skipped with a parallel make check!
>> I.E. this first command detects the fail, while the second skips the test:
>>   $ make -j2 check TESTS="tests/mv/i-3.sh"
>>   $ make -j2 check TESTS="tests/mv/i-2.sh tests/mv/i-3.sh"
>>
>> So to handle both cases I'm updating the "release tasks" list to:
>>   setsid make check $(($(nproc) * 2)) # tests without controlling tty
>>   make check -j1 # tests with controlling tty
> 
> Thanks.
> What about a ---presume-input-tty option for mv(1) like rm(1) has?

Good point, though probably not worth it.
There is only 1 mv test dependent on tty
while there are 5 rm tests dependent on tty.
We should add ---presume-input-tty if we add more tests like that though.

thanks,
Pádraig.

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

From: karl <at> freefriends.org (Karl Berry)
To: P <at> draigBrady.com, 17087 <at> debbugs.gnu.org
Subject: Re: bug#17087: cp -i/yes gets ignored
Date: Thu, 27 Mar 2014 18:12:54 GMT

    So I responded with 2 reasons why we might not make 'y' imply '-f'
    for unwritable files.

P@, I'm afraid those reasons did not make sense to me.  Can you restate?
Sorry.

To restate my own idea: from my "(not so) naive user"'s point of view,
going to the trouble of typing "y RET" is the most forceful expression
possible of the desired behavior, namely that I want the darn file to
get copied.  So, if cp -f would work, I would like answering "y" to work.

(And, I believe the other user's request amounts to saying "if cp -f
would not work, then don't even bother to ask me".  I don't feel
strongly about that request. :)

    code complexity it never a reason for not doing something.

I suspect we all agree ... in theory :).

Thanks,
karl

Previous Next

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