tag 15105 notabug
thanks

On 08/15/2013 09:16 AM, Hai wrote:
> Hi All
> 
> If someone else have issued this thing before, please forgive my
> disturbance.
> 
> Command $mv a_file* will overwrite one of your files iff 2 files with
> the same prefix under the folder.

Yes, and this is a feature, required by POSIX.

> 
> I know we should know what we are doing with the command given by
> ourselves.
> But I think this is an unusual case, and tools should complain it.

Unfortunately, mv cannot distinguish between 'mv a*' and 'mv a1 a2' -
the globbing has already happened in the shell before mv ever sees its
command line arguments.

> Can mv check the args before parsing the data in it? 'Cause I think no
> body is going to rename a file with this kind of command 'mv a_file*',
> so there should be a potential error, and should better tell the user.

I could suggest that you consider setting up an alias in your
environment, such as:
 alias mv='mv -n '
or
 alias mv='mv -i '
so that if you type 'mv a*' and the glob expands to a valid command that
would overwrite the second file, then it will fail or prompt you.  But
be careful - if you create an alias by the same name, but then use a
different machine where the alias is not active, you may find that you
have become reliant on the alias doing the dirty work for you, and
losing data on the machine that lacks the alias.  Also, this would mean
that mv prompts you even when you spell out the overwrite in longhand,
and you may find yourself needing to use to '\mv a b' to avoid the
alias.  (Personally, I hate distros that pre-alias mv to 'mv -i', and
that's one of the first things that I check for and undo in my
customization of a new account on such a machine - but some people swear
by it, or distros wouldn't do it...)

In short, because there is no way to make mv behave differently if you
used a glob compared to spelling in longhand, and because there is
already an option to prevent overwrites, I don't think we need to change
anything in coreutils, so I'm closing this bug report.  Feel free,
however, to continue the conversation in this thread if you have more
questions or ideas.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org