On 02/01/2012 03:02 PM, Jim Meyering wrote: > 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. >
> If the above is still not clear, please suggest how to improve it. Well, if permissions are the only case when mv would require confirmation or -f, then it should be added to mv's description. Additionally, the info page might also have note in which cases mv will refuse to work, e.g. when "‘s’ and ‘l’ are the same file". As I'm not sure (anymore) about both, I cannot propose a wording. >> That makes me think that the implementation of the a) alternative >> just reduces to calling unlink() ... ;-) This hardlink-to-softlink case is IMHO identical to the normal hardlinks case (in which mv just unlinks the source): $ touch f1 && ln f1 f2 && ls -ogi f1 f2 6590 -rw-r--r-- 2 0 Feb 1 15:17 f1 6590 -rw-r--r-- 2 0 Feb 1 15:17 f2 $ ~/git/coreutils/src/mv f1 f2 $ ls -ogi f1 f2 ls: cannot access f1: No such file or directory 6590 -rw-r--r-- 1 0 Feb 1 15:17 f2 Therefore, I'd tend to a) again. It doesn't matter if src is a regular file or a symlink. What do you think? Have a nice day, Berny
