bug#17087: cp -i/yes gets ignored

2014-03-24 Thread Karl Berry
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 yes.  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





bug#17087: cp -i/yes gets ignored

2014-03-24 Thread Pádraig Brady
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 yes.  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.