Subject: bin/19756: Questionable behaviour of "cp -R d t" vs "cp -R d/ t", given d, t directories
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 01/09/2003 16:01:31
>Synopsis: Questionable behaviour of "cp -R d t" vs "cp -R d/ t", given d, t directories
>Arrival-Date: Thu Jan 09 07:02:00 PST 2003
>Originator: Lasse Hillerĝe Petersen
>Release: NetBSD 1.6_STABLE
System: NetBSD galaxy.toft-hp.dk 1.6_STABLE NetBSD 1.6_STABLE (BREEZE_LAPTOP) #0: Mon Dec 23 01:30:11 CET 2002 firstname.lastname@example.org:/misc/work/netbsd/src/sys/arch/i386/compile/BREEZE_LAPTOP i386
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
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.
cp -R a b
ls b # shows a
cp -R a/ c
ls c # shows f1
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.