On Thu, Nov 19, 2009 at 2:45 PM, Paul M <l...@no-tek.com> wrote:
...
> This always confused me - Presumably there is some reason why the
> implimentation
> of the -r flag could not be fixed to copy symlinks, FIFOs, etc correctly.
>
> Anybody have any insight here? Why would a new flag be needed?
To quote the RATIONALE section of the POSIX spec for 'cp':
Earlier versions of this standard included support for the -r
option to copy file
hierarchies. The -r option is historical practice on BSD and BSD-derived
systems. This option is no longer pspecified by POSIX.1-2008
but may be present
in some implementations. The -R option was added as a close
synonym to the -r
option, selected for consistency with all other options in
this volume of
POSIX.1-2008 that do recursive directory descent.
The difference between -R and the removed -r option is in the
treatment by cp
of file types other than regular and directory. It was
implementation-defined how
the -r option treated special files to allow both historical
implementations and
those that chose to support -r with the same abilities as -R
defined by this volume
of POSIX.1-2008. The original -r flag, for historic reasons,
did not handle special
files any differently from regular files, but always read the
file and copied its
contents. This had obvious problems in the presence of special
file types; for
example, character devices, FIFOs, and sockets.
So:
1) because they were standardizing on -R for that behavior in other
utilities (along
with the -H, -L, and -P options)
2) because you don't *know* that someone isn't depending on the
existing behavior
of the -r option in some script. I can *easily* imagine a script
that depends on
symlinks being chased (I think I wrote one myself at some point a
decade ago);
OS developers generally don't like to break their customer's
programs. Consider
that Solaris *still* ships with a horribly broken /bin/sh; do you
really think they'll
change this just because POSIX says so?
Philip Guenther
