Did this work? mv -n AAA BBB
Not possible to tell in the simple case where BBB may or may not already exist. We could check the result - has AAA gone? - but it's now a race condition. We could turn on --verbose and try to parse the results, although --verbose output probably isn't guaranteed stable. The atomicity benefits of renameat2's RENAME_NOREPLACE are exposed with --no-clobber but the resulting EEXIST code suppressed. Would it be worthwhile having an option e.g. --no-clobber=fail to modify the exit status when mv didn't perform the rename? I haven't thought too hard about the semantics of moving a bunch of files to a target directory, but we presumably have to deal with this today for -i / -b. The use case is simply race-free renames. Imagine all the locking schemes you could implement with mv(1)! Cheers, Phil
