bug#17578: cp(1) man page: behavior of "cp -R dir target" on symbolic links is unclear

[Pádraig Brady]

tag 17578 wontfix
close 17578
stop

On 05/25/2014 09:27 PM, Paul Eggert wrote:
> Pádraig Brady wrote:
>>    -  -R, -r, --recursive          copy directories recursively
>>    +  -R, -r, --recursive          copy directories recursively (implies -P)
> 
> Unfortunately it's not that simple, as -R doesn't always imply -P.

Yes we shouldn't assume users would know that -H and -L would override -P.
Also --link is recently wound up in this. Hence it's not easy to describe.
We could accurately describe using something like the following, but given
that the info docs are correct and complete here and that most users use
-a anyway which already explicitly considers --no-dereference, it's probably
best to err on the side of conciseness in the man/--help and let users
refer to info for complete docs.

thanks,
Pádraig.

diff --git a/src/cp.c b/src/cp.c
index 243d6af..878266a 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -206,7 +206,8 @@ Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.\n\
       --parents                use full source file name under DIRECTORY\n\
 "), stdout);
       fputs (_("\
-  -R, -r, --recursive          copy directories recursively (implies -P)\n\
+  -R, -r, --recursive          copy directories recursively. Without -H,-L 
or\n\
+                                 --link, implies --no-dereference\n\
       --reflink[=WHEN]         control clone/CoW copies. See below\n\
       --remove-destination     remove each existing destination file before\n\
                                  attempting to open it (contrast with --force)\