848263aad1
As noted in the PR, cp -R has some surprising behavior. Typically, when you `cp -R foo bar` where both foo and bar exist, foo is cleanly copied to foo/bar. When you `cp -R foo foo` (where foo clearly exists), cp(1) goes a little off the rails as it creates foo/foo, then discovers that and creates foo/foo/foo, so on and so forth, until it eventually fails. POSIX doesn't seem to disallow this behavior, but it isn't very useful. GNU cp(1) will detect the recursion and squash it, but emit a message in the process that it has done so. This change seemingly follows the GNU behavior, but it currently doesn't warn about the situation -- the author feels that the final product is about what one might expect from doing this and thus, doesn't need a warning. The author doesn't feel strongly about this. PR: 235438 Reviewed by: bapt Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D33944 |
||
---|---|---|
.. | ||
cat | ||
chflags | ||
chio | ||
chmod | ||
cp | ||
csh | ||
date | ||
dd | ||
df | ||
domainname | ||
echo | ||
ed | ||
expr | ||
freebsd-version | ||
getfacl | ||
hostname | ||
kenv | ||
kill | ||
ln | ||
ls | ||
mkdir | ||
mv | ||
pax | ||
pkill | ||
ps | ||
pwait | ||
pwd | ||
realpath | ||
rm | ||
rmail | ||
rmdir | ||
setfacl | ||
sh | ||
sleep | ||
stty | ||
sync | ||
test | ||
tests | ||
uuidgen | ||
Makefile | ||
Makefile.inc |