GNU bug report logs - #6104
[Expert] Bug in mv?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6104 in the body.
You can then email your comments to 6104 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Gene Heskett <gene.heskett <at> gmail.com>
To: expert <at> mandrivalinux.org, bug-coreutils <at> gnu.org
Subject: Re: [Expert] Bug in mv?
Date: Tue, 04 May 2010 23:09:01 -0400

On Tuesday 04 May 2010, João Victor Martins wrote:
>On Tue, May 04, 2010 at 10:36:19PM -0400, Gene Heskett wrote:
>> I tried to "mv amanda* /home/amanda/*" as root and which
>> which I recall I have done successfully several times before.
>
>The shell expand * _before_ passing the args to mv.  So mv saw all
>files starting with 'amanda' and all files (besides . hidden ones) in
>/home/amanda/ as arg.  It then picked the last one listed (probably
>/home/amanda/tmp/) as destination.
>
I had two files whose names started with amanda in that directory.  I would 
have assumed it would expand the src pattern of "amanda*" to match only those 
two files.  And the rest of the files in /home/me, weren't bothered.  No 
damages to the src directory at all other than removing the files.

If it expanded that * to include the whole thing, it should have moved the 
whole thing.  It didn't.  In past experience, the target path spec's /* has 
always served as just a place holder for the filenames actually selected by 
the amanda* in the src spec.  That is not what it did this time.  This time 
it created a tmp/ directory in /home/amanda, moved the whole amanda tree to 
the tmp directory, including the two files I actually asked it to move from 
/home/me/Download.  No loss, but a very surprised veteran linux user.

Someplace, the plans of mice and men have definitely gone aglay here, so I've 
included bug-coreutils <at> gnu.org.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Every nonzero finite dimensional inner product space has an orthonormal 
basis.

It makes sense, when you don't think about it.

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

From: Eric Blake <eblake <at> redhat.com>
To: Gene Heskett <gene.heskett <at> gmail.com>
Cc: 6104 <at> debbugs.gnu.org, expert <at> mandrivalinux.org
Subject: Re: bug#6104: [Expert] Bug in mv?
Date: Wed, 05 May 2010 15:02:56 -0600

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

On 05/04/2010 09:09 PM, Gene Heskett wrote:
> On Tuesday 04 May 2010, João Victor Martins wrote:
>> On Tue, May 04, 2010 at 10:36:19PM -0400, Gene Heskett wrote:
>>> I tried to "mv amanda* /home/amanda/*" as root and which
>>> which I recall I have done successfully several times before.
>>
>> The shell expand * _before_ passing the args to mv.  So mv saw all
>> files starting with 'amanda' and all files (besides . hidden ones) in
>> /home/amanda/ as arg.  It then picked the last one listed (probably
>> /home/amanda/tmp/) as destination.

This analysis is correct.

>>
> I had two files whose names started with amanda in that directory.  I would 
> have assumed it would expand the src pattern of "amanda*" to match only those 
> two files.  And the rest of the files in /home/me, weren't bothered.  No 
> damages to the src directory at all other than removing the files.
> 
> If it expanded that * to include the whole thing, it should have moved the 
> whole thing.  It didn't.  In past experience, the target path spec's /* has 
> always served as just a place holder for the filenames actually selected by 
> the amanda* in the src spec.

Huh?  Globbing has never worked like that.  Globbing is done by the
shell, not by mv, so by the time mv is started, the * has already been
converted into one or more filenames.

Maybe you are thinking of the rename(1) or mmv(1) utility provided by
some distros (but not part of coreutils), where, with proper quoting (so
that the * goes through as argv of the rename command, which then does
the pattern manipulation you wanted.  But mv(1) is specified by POSIX,
and has never done pattern manipulation.  The glob in your second
argument is expanded by the shell independently of the * in the first
argument, and mv never knows that either variant was a glob.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: gene.heskett <at> gmail.com (Gene Heskett)
Cc: 6104 <at> debbugs.gnu.org, expert <at> mandrivalinux.org
Subject: Re: bug#6104: [Expert] Bug in mv?
Date: Wed, 5 May 2010 16:10:46 -0500 (GMT+5)

Note: I saw this on bug-coreutils, haven't read the whole thread.

Gene Heskett writes:
> 
> On Tuesday 04 May 2010, Jo=E3o Victor Martins wrote:
> >On Tue, May 04, 2010 at 10:36:19PM -0400, Gene Heskett wrote:
> >> I tried to "mv amanda* /home/amanda/*" as root and which
> >> which I recall I have done successfully several times before.
> >
> >The shell expand * _before_ passing the args to mv.  So mv saw all
> >files starting with 'amanda' and all files (besides . hidden ones) i=
> n
> >/home/amanda/ as arg.  It then picked the last one listed (probably
> >/home/amanda/tmp/) as destination.
> >
> I had two files whose names started with amanda in that directory.  I
>  would
> have assumed it would expand the src pattern of "amanda*" to match on
> ly those

It's not the first * that's the problem. The second one (/home/amanda/*)
expands to a list of everything that was in /home/amanda (except dotfiles)
and that happens before mv is executed. There are several possibilities of
what that command can do:

1. /home/amanda contained no files before the move. In that case the
/home/amanda/* is passed through literally as the final argument to mv, so mv
sees 3 arguments (your 2 files, then "/home/amanda/*" which doesn't exist)
and it fails, because with more than 2 arguments, the last argument must be
an existing directory.

2. /home/amanda contained some stuff, and the last item in the expanded list
(alphabetically sorted) was not a directory. Same result as #1.

3. /home/amanda contained some stuff, and the last item in the expanded list
happened to be a directory (say you have a directory called
/home/amanda/zzzzzzzz): then the list expands, the final argument to mv is an
existing directory, so you have success! Your 2 files, plus everything in
/home/amanda, gets moved into the zzzzzzzz directory. If this isn't what you
meant, you did something wrong. mv just did what it was told.

4. Like #1, but with a nomatch shell option enabled, you get a "No match"
error message.

Your career as a unix wizard isn't complete until you've done something like
#3 *on purpose*.

-- 
Alan Curry

Previous Next

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