bug-bash
[Top][All Lists]
Advanced

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

Re: cp command will copy to subdirectory without appending /


From: Marc Herbert
Subject: Re: cp command will copy to subdirectory without appending /
Date: Wed, 21 Oct 2009 17:53:24 +0100
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Bob Proulx a écrit :
> Todd Partridge wrote:
 
> If the target has an appended '/' then the destination must be a directory.

But with cp (GNU coreutils) 6.12, appending '/' to the target does not seem
to make any difference?

 
>> I think the proper behavior here for 'cp -R test2 test' would be to
>> error and print that 'Folder already exists'.
> 
> Of course that would break decades of scripts which expect the
> standard behavior.  I don't understand why would you change this long
> standing useful behavior.  Could you say a few words more about what
> your problem is with the current behavior?

The problem is dead-simple. You cannot run this command multiple times:

    cp -R  ./dirfoo  ./dirfoo.backup

That's all.


The usual workaround is to "rm -rf ./dirfoo.backup" systematically. It
is tedious and easy to forget. And it prevents adding any non-dirfoo
content to dirfoo.backup.

cp is too clever. It should not behave in a completely different way
depending on the external environment. It should ideally depend only on
the user input (that is: trailing slash or not). <pedantic>This is
called "Referential transparency"</pedantic>

rsync's opinion on this topic is interesting. The "rm -rf" workaround is
obviously not acceptable for rsync. But rsync did not want to depart
from existing syntax either. So rsync added its own, somewhat funny
workaround: appending a trailing slash to the source directory.

 
>> Appending a / would imply the directory:
>> cp -R test2 test/
>> This usage will remove the ambiguity of the command between the copy
>> function and the rename function.


> Please rephrase your question and send it to address@hidden

This is probably not worth the hassle considering that any change would
break decades of scripts.






reply via email to

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