Bernhard Voelker wrote:
...
> well, if it's not standardized (yet), then I agree with you that we
> should choose the simpler b) alternative.
>
> Do you think it's work thinking about the -f case?
>
> $ ~/git/coreutils/src/mv -f s l
> /home/berny/git/coreutils/src/mv: ‘s’ and ‘l’ are the same file
mv's -f option is unrelated to this case.
It relates solely to controlling whether one is prompted
due to permissions or -i.
>From 'info mv's description of the common case (no options):
If a destination file exists but is normally unwritable, standard
input is a terminal, and the `-f' or `--force' option is not given,
`mv' prompts the user for whether to replace the file. (You might own
the file, or have write permission on its directory.) If the response
is not affirmative, the file is skipped.
Yes, it is unfortunate that the standards-imposed semantics
of -f is different from what we'd expect.
> The info pages are not quite clear in which cases mv tries to
> overwrite the destination. Usually, I am tempted to think that
> a "--force" will "just do it" - regardless of data loss.
> But in this case, mv "just does not" and the only thing left
> is to rm that hardlink.
If the above is still not clear, please suggest how to improve it.
> That makes me think that the implementation of the a) alternative
> just reduces to calling unlink() ... ;-)
