Kamil Dudka <kdu...@redhat.com> wrote: > On Wednesday 07 January 2009 08:35:24 Jim Meyering wrote: >> Have you considered other long-option names? >> I prefer --no-clobber. or maybe --no-overwrite > In this case I prefer --no-overwrite, but feel free to change it.
Hi Kamil, --no-clobber gets a few more matches in C sources than --no-overwrite, 57 http://www.google.com/codesearch?q=\-\-no\-clobber+lang:c 40 http://www.google.com/codesearch?q=\-\-no\-overwrite+lang:c Regarding uses, it appears to outnumber --no-overwrite 2-to-1. Anyone else have a preference? >> ----------------------- >> Please adjust the NEWS entry: >> >> - cp/mv new option -n to not overwrite target >> + cp and mv accept a new option, --LONG_OPTION (-n): silently refrain >> + from overwriting any existing destination file >> >> ----------------------------- >> You haven't mentioned how this new option interacts with --backup, >> another option that prevents loss of any existing destination file. >> >> Since with --backup, cp and mv arrange to move any destination aside, >> one might expect -n --backup to be equivalent to --backup. > The behavior is the same as for -i option with negative user's response. If > nothing is going to be overwritten, there is nothing to backup. I think this > is an expected behavior and in this way is the --backup option already > documented. My point is that depending on when you test for the existence of the destination file, you could say that with --backup, there is never an existing destination file, since it's always moved aside before the "open". In *that* case, you would expect the "-n" in "--backup -n" to be ignored. This ambiguity is why the semantics of "--backup -n" must be documented explicitly. Since there are three copies of that new sentence in coreutils.texi, If you specify more than one of the @option{-i}, @option{-f}, @option{-n} options, only the final one takes effect. would you please put it in a macro? Thanks for being patient. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
