[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 bug-coreutils@gnu.org.
This is probably not worth the hassle considering that any change would
break decades of scripts.