cp -r is meant to copy files recursively, and
cp -R for copying directories recursively. But I've checked, and both appear to copy both files and directories, the same thing. So, what's the difference actually?
-R is posix well-defined,
-r is not portable!
On Linux, in the GNU and BusyBox implementations of
-R are equivalent.
On the other side, as you can read in the POSIX manual page of
-r behavior is implementation-defined.
* If neither the -R nor -r options were specified, cp shall take actions based on the type and contents of the file referenced by the symbolic link, and not by the symbolic link itself. * If the -R option was specified: * If none of the options -H, -L, nor -P were specified, it is unspecified which of -H, -L, or -P will be used as a default. * If the -H option was specified, cp shall take actions based on the type and contents of the file referenced by any symbolic link specified as a source_file operand. * If the -L option was specified, cp shall take actions based on the type and contents of the file referenced by any symbolic link specified as a source_file operand or any symbolic links encoun- tered during traversal of a file hierarchy. * If the -P option was specified, cp shall copy any symbolic link specified as a source_file operand and any symbolic links encoun- tered during traversal of a file hierarchy, and shall not follow any symbolic links. * If the -r option was specified, the behavior is implementation- defined.
-r was an older option, introduced in 4.1BSD, which would simply copy all non-directories as files. That is, if it encountered a device or FIFO, it would open it, read the contents, and create a file at the destination with the contents.
-R was a standardized option (introduced to BSD in 4.4BSD, though earlier versions had it as a synonym to
-r) which would, on encountering a device, FIFO, or other special file, make an equivalent special file at the destination.
Many implementations do still maintain this distinction, but some (including the GNU version typical to Linux) only provide the
-R semantics, with
-r as a synonym.
In OS X and old versions of FreeBSD
-r is like
-R -L --copy-contents in coreutils, or it follows symlinks and reads the contents of special files and FIFOs.
mkdir a;touch b;ln -s $PWD/b a;cp -r a c replaces the symlink with the target file in OS X,
mkdir a;mkfifo a/b;cp -r a c gets blocked reading the FIFO, and
mkdir a;ln -s /dev/zero a;cp -r a b starts filling
b/zero with zeroes.
cp man page in OS X and old versions of FreeBSD:
Historic versions of the cp utility had a -r option. This implementation supports that option; however, its use is strongly discouraged, as it does not correctly copy special files, symbolic links, or fifo's.
In new versions of FreeBSD
-r is equivalent to
Historic versions of the cp utility had a -r option. This implementation supports that option, however, its behavior is different from historical FreeBSD behavior. Use of this option is strongly discouraged as the behavior is implementation-dependent. In FreeBSD, -r is a synonym for -RL and works the same unless modified by other flags. Historical imple- mentations of -r differ as they copy special files as normal files while recreating a hierarchy.
If copying recursively, copy the contents of any special files (e.g., FIFOs and device files) as if they were regular files. This means trying to read the data in each source file and writing it to the destination. It is usually a mistake to use this option, as it normally has undesirable effects on special files like FIFOs and the ones typically found in the
/devdirectory. In most cases,
cp -R --copy-contentswill hang indefinitely trying to read from FIFOs and special files like
/dev/console, and it will fill up your destination disk if you use it to copy
/dev/zero. This option has no effect unless copying recursively, and it does not affect the copying of symbolic links.