Paul Eggert wrote:
Brendan Byrd/SineSwiper <[EMAIL PROTECTED]> writes:
+ All source file names must be absolute (starting with @samp{/}) unless the + destination files are in the current directory.
This seems like a serious limitation. Can't you remove it, by using canonicalize_file_name say?
This limitation also exists in the "cp -s" command. I copied that line from the "cp -s" docs. Example:
[EMAIL PROTECTED]:~/tmp/a> mv -s b/f . mv: `b/f': can make relative symbolic links only in current directory
[EMAIL PROTECTED]:~/tmp/a/b> cp -s f .. cp: `../f': can make relative symbolic links only in current directory
So, it looks like it's expected behavior. One annoying thing I found with that, is that it says that error message AFTER it's moved and tried to create a symlink with the file. So you end up with the file already moved, and a broken symlink in tmp/a/b called [f -> ./f].
This may be related to the un-implemented (or rather un-ported from copy.c) "goto un_backup" routine. At the very least, it should exit before the symlink call. I'm going to try to fix the original problem by moving that current directory check to the beginning of the do_move sub.
BTW, can anybody explain the purpose of the backup function in the "mv" command? I'd like to port the un_backup stuff, but I'm not quite sure how it works, or even if it's worth porting. (Does anybody make backups during a move, even with so much error checking to ensure the file was moved?)
Also, what happens with examples like "mv -s f .."?
Works just fine:
[EMAIL PROTECTED]:~/tmp/a/b> mv -s f .. [EMAIL PROTECTED]:~/tmp/a/b> dir total 0 lrwxrwxrwx 1 blkb users 4 2004-11-19 00:14 f -> ../f
-- Brendan Byrd/SineSwiper <[EMAIL PROTECTED]> Computer techie, Perl hacker, and all-purpose Internet guru Resonator Software (http://www.ResonatorSoft.org/)
_______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
