Kamil Dudka <kdu...@redhat.com> wrote:
> On Wednesday 07 January 2009 17:08:04 Jim Meyering wrote:
>> --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?
> Now the option is --no-clobber in attached patch. Anyway the change is
> trivial. No problem to change it if there will be a consensus
> for --no-overwrite or something else.
>
>> 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.
> Ok, mentioned in documentation of option -n.
>
>> 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?
> Ok, new patch attached.
Thanks! Almost done, I think.
Unless anyone pipes up about the choice of long option name.
> +...@item -n
> +...@itemx --no-clobber
> +...@opindex -n
> +...@opindex --no-clobber
> +Do not overwrite an existing file. The @option{-n} option overrides a
> previous
> +...@option{-i} option. This option turns off the backup.
These semantics might be a little surprising, or even dangerous.
Imagine I run cp -n --backup=numbered important-file backup,
thinking that it's just made a backup of the old version and
I can now safely destroy "important-file".
What do you think about making cp/mv fail if -n and --backup are used together?
Then there would be no risk of misunderstanding.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
