Bug 436083

Summary: cp -i -f should act sensibly
Product: [Fedora] Fedora Reporter: JW <ohtmvyyn>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-05 12:03:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.