cp command will copy to subdirectory without appending /

The cp command will copy to a subdirectory without an appending /

mkdir test test2
touch abc test
touch bcd test2
cp -R test2 test
ls test
test2 abc

Since the cp command can also rename I think the proper behavior here
for 'cp -R test2 test' would be to error and print that 'Folder
already exists'.  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.

--
When in trouble or in doubt run in circles, scream and shout. - Robert
A. Heinlein
My Linux Blog - http://linuxtidbits.wordpress.com

[Bob Proulx]

Todd Partridge wrote:
> The cp command will copy to a subdirectory without an appending /

You have reached bug-bash, not bug-coreutils.  The 'cp' program is in
the GNU Coreutils project and so bug reports for 'cp' should go to
bug-coreutils@... and not to bug-bash.  The bug-bash list is for
bugs and discussion about bash.

> mkdir test test2
> touch abc test
> touch bcd test2

I think you have typed this in incorrectly.  That produces:

  ./abc
  ./bcd
  ./test
  ./test2

> cp -R test2 test

Because test is a directory test2 will be copied into that directory.
With the above that produces:

  ./abc
  ./bcd
  ./test
  ./test/test2
  ./test2

> ls test
> test2 abc

That result cannot be produced from the given commands.  Please
rephrase the question.

> Since the cp command can also rename

I think you misunderstand how cp works.  A quick and casual summary
here.  If the target is not a directory then the source file
(singular) is copied to the destination.  If the target is a directory
then cp copies the source files (one or more) into the destination
directory.  If the target has an appended '/' then the destination
must be a directory.

Here is the full standards document:

  http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html

> 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?

> 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@....

Thanks
Bob

On Tue, Oct 20, 2009 at 12:59 AM, Bob Proulx <bob@...> wrote:

> Todd Partridge wrote:
>> The cp command will copy to a subdirectory without an appending /
>
> You have reached bug-bash, not bug-coreutils.  The 'cp' program is in
> the GNU Coreutils project and so bug reports for 'cp' should go to
> bug-coreutils@... and not to bug-bash.  The bug-bash list is for
> bugs and discussion about bash.
>
>> mkdir test test2
>> touch abc test
>> touch bcd test2
>
> I think you have typed this in incorrectly.  That produces:
>
>  ./abc
>  ./bcd
>  ./test
>  ./test2

Yes, I did.  The correct syntax, would be:

mkdir test test2
touch abc test/
touch bcd test2/

>
>> cp -R test2 test
>
> Because test is a directory test2 will be copied into that directory.
> With the above that produces:
>
>  ./abc
>  ./bcd
>  ./test
>  ./test/test2
>  ./test2
>
>> ls test
>> test2 abc
>
> That result cannot be produced from the given commands.  Please
> rephrase the question.

? I was tired last night :), the good typing would be:

ls test/
test2  abc

>
>> Since the cp command can also rename
>
> I think you misunderstand how cp works.  A quick and casual summary
> here.  If the target is not a directory then the source file
> (singular) is copied to the destination.  If the target is a directory
> then cp copies the source files (one or more) into the destination
> directory.  If the target has an appended '/' then the destination
> must be a directory.

Because the cp command also renames, I understand the default behavior
to assume that you want to cp.  But I believe the default behavior to
assume a directory 'test/'  when typing 'test' would lead to more
problems for advanced users.  Feedback that 'directory already exists'
I think would be a more direct behavior.  Hmm.

>
> Here is the full standards document:
>
>  http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html
>
>> 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?

Yeah, well there is little doubt that this would break things :).  For
advanced users I would actually see this as a benefit though we
probably are all responsible for the occasional forgetting of
appending a backslash.

>
>> 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@....
>
> Thanks
> Bob
>

Appreciate the email bob, will get with bug-coreutils@....



--
When in trouble or in doubt run in circles, scream and shout. - Robert
A. Heinlein
My Linux Blog - http://linuxtidbits.wordpress.com

[Marc Herbert-6]

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@....

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

[Marc Herbert-5]

> The problem is dead-simple. You cannot run this command multiple times:
>
>     cp -R  ./dirfoo  ./dirfoo.backup
>

Sorry to add yet another (last) off topic message but I must do justice
to GNU cp.  GNU cp actually does support the above thanks to a
(non-standard) option:

     cp -R -T ./dirfoo  ./dirfoo.backup

For details see:  info coreutils "Target Directory"