bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question for cp tools


From: Jim Meyering
Subject: Re: question for cp tools
Date: Sat, 05 Mar 2005 09:31:14 +0100

Hi Bob,

I've noticed that my use of `source' below might be misunderstood.
Here's a snippet from the documentation that should help:

     mv [OPTION]... SOURCE DEST
     mv [OPTION]... SOURCE... DIRECTORY

address@hidden (Bob Proulx) wrote:
...
> I know this is one of the features that you really like.

Hmm... I wouldn't go that far :)
I think it's a worthwhile feature, since it can help naive or
careless users avoid accidentally destroying their SOURCE files.

> I often have cases where I have duplicate files here and there in a
> directory tree.  For various reasons I want to move them to the
> archive.  If they are named the same they have the same contents so I
> only want to keep exactly one copy of them.  So I want
>
>   mv */*/foo ../ARCHIVE/
>   mv $(find . -name foo -print)../ARCHIVE/
>
> to move those files to the target directory.  But of course with the
> duplicate check in place that fails.  So then I started using a for
> loop so that it would be different mv commands.
>
>   for f in */*/foo; do mv $f ../ARCHIVE/

In general, you can add mv's --backup option:

   mv --backup=numbered */*/foo ../ARCHIVE/

then you'll find like-named files with suffixes like .~1~, .~2~, etc.
in your ARCHIVE directory.  Personally, I've been happy to have mv aliased
to `mv --backup=numbered' for as long as GNU mv has had that option.
Of course, if they're really all the same, you won't want to archive
the ~-backup files.

> That works but is a lot of typing.  If the -f option forced the move
> then I would be happy with that.  The documentation explicitly says it
> will overwrite files.
>
>      -f, --force
>           do not prompt before overwriting (equivalent to --reply=yes)

Well, we can't really use -f/--force, because -f has POSIX-specified
behavior controlling whether mv prompts -- not whether it refuses to
do something that might be confusing.  Besides, --force applies to
*destination* files, which is a little ambiguous in this case, since a
SOURCE file is moved to its destination, and later mv sees that renamed
SOURCE file as the destination for another move.

>>   * mv (likewise for cp), now fails rather than silently clobbering one of
>>       the source files in the following example:
>>       rm -rf a b c; mkdir a b c; touch a/f b/f; mv a/f b/f c
>
> (Don't read too much sarcasm into this next statement.)
> I am hoping there are no plans to make this fail.
>
>   touch foo bar
>   mv foo bar
>
> Because currently that also silently clobbers files.  But that is just
> the way I like it!

:-)
The key phrase above is `clobbering one of the *SOURCE* files'.

The difference is that `mv foo bar' unlinks a *destination* file,
which is what everyone expects mv to do.  Few realize that a
POSIX-compliant mv can sometimes clobber *SOURCE* files, too.

Jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]