GNU bug report logs - #69532
mv's new -x option should be made orthogonal to -t/-T/default

Previous Next

Full log

Message #8 received at 69532 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 69532 <at> debbugs.gnu.org
Cc: Petr Malat <oss <at> malat.biz>
Subject: Re: bug#69532: mv's new -x option should be made orthogonal to
 -t/-T/default
Date: Mon, 4 Mar 2024 15:47:23 +0000

On 04/03/2024 00:44, Paul Eggert wrote:
> Although I like the idea of exposing file swaps to the user, the first
> cut of 'mv -x' has significant problems.
> 
> I expect 'mv -x A B' to act like 'mv A B' except the destination must
> exist and is renamed back to A. However, this is not true for 'mv -x A
> B' when B is a directory; it renames B to A rather than renaming B/A to
> A as I expect. That is, 'mv -x' acts as if -T (--no-target-directory) is
> also specified. There is no way to get mv's traditional behavior, or to
> get mv -t behavior.
> 
> 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.
> 
> This needs to happen before the next coreutils release, to avoid
> confusion about 'mv -x'.

So you're saying the current mv -x behavior should only be with -T explicitly specified.
With the current implementation, we should at least document that -x implies -T.

By changing as you suggest, we'd not be adding any significant functionality,
but potentially reducing confusion by following mv traditional arg handling.
I agree with you I think, but not strongly.

It's worth stating though that if users want to swap 2 directories
they'd have to `mv -Tx d1 d2`, which may also be a little confusing.

The use case we don't currently support directly is:
cd source_dir && mv -x * "$dest_dir"
Instead that currently requires:
for f in *; do mv -x "$f" "$dest_dir"; done

For completeness, stating disadvantages of pulling this use case within mv,
is that by requiring the for loop for this would allow users
to programatically determine which swap failed, and I see --swap
as primarily a programatic interface used by scripts.
Also if we made this change, We'd have to document that `mv -x 1 2 ... d`
was not atomic over the whole set.

I will look at making the change before the upcoming release.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.