mv(1) behaves oddly with hard links. Create two files which are links to the same inode:
% mkdir test % cd test % touch a % ln a b % ls a b Now try mv-ing one to the other: % mv -v a b && echo yes `a' -> `b' yes % ls a b It's not so much the fact that mv is not doing anything that suprises me, but that it returns a true exit status and even prints the '->' message even though no file was moved! Even the -f option will not convince mv to move the files: % mv -vf a b && echo yes `a' -> `b' yes % ls a b I would have expected that when source and destination are the different names for the same inode, mv would just unlink the source. Or indeed behave as it normally does when asked to overwrite an existing destination name. Perhaps the current peculiar behaviour is mandated by POSIX (although it is not documented in the mv(1) manual page or info documentation). If so, is there anything you can do, within the POSIX standard, to make mv's behaviour less surprising? Perhaps printing a warning that since source and destination are the same inode nothing will be moved. Or a new option --force-yes-really-i-mean-it which will do the move even in this case. Or at the least, mv -v should not print its message to stderr unless it really is moving the file. (On HP-UX, /bin/mv will report 'a and b are identical', which seems a small improvement.) % mv --version mv (fileutils) 4.1 Written by Mike Parker, David MacKenzie, and Jim Meyering. Copyright (C) 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % uname -a HP-UX lonhp01 B.11.11 U 9000/800 589734997 unlimited-user license -- Ed Avis <[EMAIL PROTECTED]> _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
