Bug 436083 - cp -i -f should act sensibly
Summary: cp -i -f should act sensibly
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
(Show other bugs)
Version: 8
Hardware: All Linux
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-05 09:49 UTC by JW
Modified: 2008-03-05 12:03 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-05 12:03:26 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description JW 2008-03-05 09:49:37 UTC
Description of problem:
If both -i and -f options (in that order) are specified to cp then cp should not
act interactively. Conversely, if -f and -i options (in that order) are
specified then -f should be ignored.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. unalias cp
2. touch a b
3. cp -i -f a b
4. cp -f -i a b
Actual results:
3. prompts
4. prompts

Expected results:
3. no prompt
4. prompt

Additional info:
In a sense -i and -f are complimentary.  That is, -i means ask, and -f means
don't ask.  Often users will alias cp='cp -i' to avoid clobbering files.  But
then when they really want to overwrite files unconditionally they will use 'cp
-f' which will translate to 'cp -i -f'.  While it is entirely possible to use
'\cp -f' that assumes that the user is fully conscious of any cp alias in effect.

It would make a lot more sense to have both -f and -i use the same internal
flag, rather than distinct "unlink_dest_after_failed_open" and "interactive",
and thereby the final -i/-f would be the flag that endures.

Comment 1 Ondrej Vasik 2008-03-05 12:03:26 UTC
from cp info page:
     This option is independent of the `--interactive' or `-i' option:
     neither cancels the effect of the other.

So IMO this options work as designed and this behaviour is not a bug. 
POSIX specification (defines this behaviour):
Upstream report with answer:

I'm not going to break POSIX definitions and to create fork of cp in this case,
 therefore closing NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.