On Mon, Mar 04, 2024 at 04:24:27PM -0800, Paul Eggert wrote: > On 3/4/24 15:37, Petr Malat wrote: > > Why do you expect this? > > I expect it because mv has always treated destination directories that way. > This has been true since the 1970s. We should not change this basic mode of > operation.
But it doesn't behave like that when one uses -T, which is fine, because it's documented. > > > To fix this, 'mv -x' should respect the usual mv behavior with respect to > > > directories. For example, when D is a directory 'mv -x A B C D' should act > > > like 'mv A B C D' except that D's old entries should be renamed back to A > > > B > > > and C. And the -t and -T options should work with -x the same way they > > > work > > > when -x is not specified. > > > > I do not think this is a good idea, because that operation is not > > atomic. > > There's nothing wrong with 'mv -x a b c d/' being nonatomic. "mv a b c d/" > is not atomic either, and that's fine too. The swap option description explicitly says it's atomic and the atomicity was the only motivation for adding the new option. > > Probably, the user wants to prepare a temporary directory > > instead and then atomically swap it with the directory in use. > > This usage was not at all obvious to me. If it's the intended use, I suggest > inventing a new command, or adding -x to the 'rename' command instead. > Pushing this flag onto 'mv', without making the flag reasonably orthogonal > to mv's other options, would be a mistake because it would cause too much > confusion. The problem with a new command is that it's hard to find and rename seems worst fitting than mv, because its main purpose is to replace a pattern in a filename (e.g. change .JPG to .jpeg), so to "implement" mv A B with rename one has to do rename A B A Implementing atomic swap operation there doesn't seem logical to me, I would never look for such a feature there. On the other hand when I call mv A B, I'm generally interested in knowing if there is a time frame, when no version of B exists. > > Supporting swap for more than 2 files also brings a problem, when > > the operation fails as then one doesn't know what has been swapped > > and what not. > > I don't see why not. The user can look at mv's diagnostics. It's the same as > regular "mv a b c d/". I don't find parsing diagnostics reliable and in general, it's something I try to avoid in scripts. In a case I would do something like mv *.X d/, and mv would fail, I would rather iterate over *.X than parse the output to handle the error. Petr