>Number:         19756
>Category:       bin
>Synopsis:       Questionable behaviour of "cp -R d t" vs "cp -R d/ t", given d, t directories
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 09 07:02:00 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Lasse Hillerĝe Petersen
>Release:        NetBSD 1.6_STABLE
>Organization:
	
>Environment:
	
	
System: NetBSD galaxy.toft-hp.dk 1.6_STABLE NetBSD 1.6_STABLE (BREEZE_LAPTOP) #0: Mon Dec 23 01:30:11 CET 2002 lhp@cloudmaster.toft-hp.dk:/misc/work/netbsd/src/sys/arch/i386/compile/BREEZE_LAPTOP i386
Architecture: i386
Machine: i386
>Description:
	cp -R directory targetdir
behaves different from
	cp -R directory/ targetdir
The first form copies the directory recursively into the targetdir, whereas the second
copies the files in the directory recursively into the targetdir, that is, it behaves
as
	cp -R directory/* targetdir

The second form is easily produced mistakenly by tab-completion when the first was
intended, and the third form is easily achievable by adding an explicit '*'.

Searching google indicates some discussion on the behaviour of cp given trailing
slashes, but it seems mostly to relate to cases involving symbolic links.

Upon reading http://www.opengroup.org/onlinepubs/007904975/utilities/cp.html, I don't see
how the current behaviour can be correct.
>How-To-Repeat:
mkdir testdir
cd testdir
mkdir a
touch a/f1
mkdir b
cp -R a b
ls b # shows a
mkdir c
cp -R a/ c
ls c # shows f1

>Fix:
If the current behaviour is retained, I think the man page should at least indicate that
this is actually intentional, although I would have a hard time to try to understand why.
>Release-Note:
>Audit-Trail:
>Unformatted: