Subject: Re: bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

From: Paul Eggert <[email-masked]>
Date: Wed, 20 Mar 2024 13:56:44 -0700

On 3/20/24 12:43, Bernhard Voelker wrote:

> This stems from the fact that although mv(1) is a userland frontend
> for renameat(2), the user interface is different:
> while renameat(2) deals exactly with 2 operands, mv(1) has always
> been able to work on more arguments.

Yes, that's mv's original sin, which we cannot realistically change now.

> Now, extending "exchange" to more arguments is confusing and the
> use is not intuitive:
>    mv -v --exchange  a b c d
> 
> An "exchange" can literally only be applied to 2 files,

Sure, but that's true for "rename" too: a "rename" can be applied only 
to 2 files.

When d is a directory, "mv a b c d" does three renames so it is like "mv 
a d/a; mv b d/b; mv c d/c". This remains true if you uniformly replace 
"mv" with "mv --exchange", which does three exchanges.

> I have the gut feeling that we didn't think through all cases,
> and that some might be surprising, e.g.:
> 
>    $ mkdir d; echo 1 > a; echo 2 > d/a
>    $ src/mv --exchange a a a a d/a
> 
> versus
> 
>    $ src/mv --exchange a a a a d/a

I don't understand the word "versus" here, as the two examples look the 
same to me.

If d/a is not a directory, the example is an error, just as it would be 
without --exchange.

If d/a is a directory and you have permissions etc., "mv a a a a d/a" is 
like attempting "mv -T a d/a/a; mv -T a d/a/a; mv -T a d/a/a; mv -T a 
d/a/a". If you use plain "mv" only the first "mv -T a d/a/a" succeeds 
because "a" goes away, so you get three diagnostics for the remaining 
three "a"s. If you use "mv --exchange" all four "mv --exchange -T a 
d/a/a" attempts succeed, and since there are an even number of exchanges 
the end result is a no-op except for updated directory timestamps. So I 
don't see any ambiguity about what mv should do with this contrived example.