Description of problem: cp --reply=HOW deprecated and the suggested alternative: cp -f doesn't work due to a default cp alias of cp -i (from root's .bashrc) Version-Release number of selected component (if applicable): coreutils-5.93-7.2 How reproducible: Always Steps to Reproduce: 1. Login as root (root alias problem) 2. Create two files 3. Use cp to try and overwrite one file with the other using --reply=yes 4. Try to follow suggestion of output (cp -f instead) *fails* 5. Follow suggestion without alias in effect *succeeds* Actual results: [root@dohslapd01 tmp]# touch foo bar [root@dohslapd01 tmp]# cp foo bar --reply=yes cp: the --reply option is deprecated; use -i or -f instead [root@dohslapd01 tmp]# cp -f foo bar cp: overwrite `bar'? [root@dohslapd01 tmp]# \cp -f foo bar [root@dohslapd01 tmp]# Expected results: [root@dohslapd01 tmp]# touch foo bar [root@dohslapd01 tmp]# cp foo bar --reply=yes cp: the --reply option is deprecated; use -i or -f instead [root@dohslapd01 tmp]# cp -f foo bar [root@dohslapd01 tmp]# Additional info: Although the --reply switch is deprecated in mv as well, it seems to not be affected with this same problem.
Alias which causes the problem: alias cp='cp -i' (located in /root/.bashrc)
Hi Tim and Derek, Without --reply=... there is no way to override cp's -i option. But neither is there a way to turn off --update, -s, -x, etc. However, if you change root's alias to use --backup=numbered instead of -i, you get the advantage of -i (not clobbering the target) without the inconvenience of being prompted. Also, as the report shows, the alias can be temporarily disabled with a leading backslash. I admit that the differences between how -i and -f work in mv and in cp can be confusing, but they are consistent with historical practice, and conform to the POSIX specs for those tools. If you feel strongly that cp should (continue to) provide such an option, please post to bug-coreutils with as much justification as possible, so the suggestion gets a wider audience.
Thanks Jim. Perhaps the answer is to change the /root/.bashrc alias to --backup=numbered then.
I've just realized there is one potential downside. While cp doesn't change the permissions of an existing destination (other than resetting special bits), cp --backup changes the target to have permissions of the source minus the bits in he umask. For root, that would present a security risk. IMHO, it's better to avoid such system-provided aliases altogether. People with root access are supposed to be clueful enough to deal with such things. But, I do see that once you've provided an option like -i by default, it becomes hard (and risky) to remove it later.
I've been giving considerable thought to the change but i'm neither happy with changing the alias nor with keeping it, though i tend to lean towards not chaning it. My reasoning for that is that if a user as root really wants to have none-interactive operation here he should use the full path of the binary like this: /bin/cp -f foo bar in order to be very clear that he/she doesn't want any influence of any kind of aliases here which could cause any kind of other sideeffects. It's the same general rule for writing secure scripts e.g., and using commands like rm, mv or cp in such an unrestricted manner should be really used carefully. Just my $0.02 Read ya, Phil
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.