GNU bug report logs - #31038
mv copies in ls -r order

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eric Blake <eblake <at> redhat.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#31038: closed (mv copies in ls -r order)
Date: Tue, 03 Apr 2018 14:19:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 3 Apr 2018 09:18:46 -0500
with message-id <213153b5-01c7-e716-abe5-32811e8eb27f <at> redhat.com>
and subject line Re: bug#31038: mv copies in ls -r order
has caused the debbugs.gnu.org bug report #31038,
regarding mv copies in ls -r order
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
31038: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31038
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-coreutils <at> gnu.org
Subject: mv copies in ls -r order
Date: Tue, 03 Apr 2018 15:52:15 +0800

$ mv -v dir1/* dir2
reveals that mv works backwards,
copying in ls -r order.
Well OK, but why is that order better than the order of the arguments it
was given?

[Message part 3 (message/rfc822, inline)]

From: Eric Blake <eblake <at> redhat.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 31038-done <at> debbugs.gnu.org
Subject: Re: bug#31038: mv copies in ls -r order
Date: Tue, 3 Apr 2018 09:18:46 -0500

[Message part 4 (text/plain, inline)]

tag 31038 notabug
thanks

On 04/03/2018 02:52 AM, 積丹尼 Dan Jacobson wrote:
> $ mv -v dir1/* dir2
> reveals that mv works backwards,
> copying in ls -r order.

Not quite true.  It copies the arguments in the order given on the
command line (the * glob expands to a sorted list according to the
current locale's sorting rules) into the directory specified as the
final argument; this is NOT the same as 'ls -r' which lists ALL
arguments in a reverse-sorted lists.

For example:

$ mkdir dir1 dir2
$ touch dir1/a dir1/b
$ echo ls -r dira1/* dir2
ls -r dir1/a dir1/b dir2
$ ls -r dira1/* dir2
dir1/b  dir1/a

dir2:

(which listed both entries under dir1 first, rather than listing dir2
first - that is, the glob expanded things in sorted order, then ls -r
reversed files within the same directory to list b before a but did NOT
reverse directories themselves).

$ mv -v dir1/* dir2
'dir1/a' -> 'dir2/a'
'dir1/b' -> 'dir2/b'

Here, mv processed all arguments in the order they were given (a before
b), which is different from what you claim as the 'ls -r' behavior (b
before a, even when the command line listed a before b).

> Well OK, but why is that order better than the order of the arguments it
> was given?

Because treating the final argument as the destination directory is how
it's been done for 40+ years, and so it was standardized that way.
Changing it now would break users.  If you don't like it, use:

mv -v --target-directory dir2 dir1/*

This is not a bug, so I'm marking it as such in the database.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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