Patch for cp(1)
Bruce Evans
bde at zeta.org.au
Sat Apr 2 00:10:10 PST 2005
On Fri, 1 Apr 2005, Tom Rhodes wrote:
> On Fri, 1 Apr 2005 20:43:02 +1000 (EST)
> Bruce Evans <bde at zeta.org.au> wrote:
>
>> On Thu, 31 Mar 2005, Tom Rhodes wrote:
>>
>>> On Thu, 31 Mar 2005 15:30:44 +1000 (EST)
>>> Bruce Evans <bde at zeta.org.au> wrote:
>>>> Any change to the semantics of -r would break applications that depend on
>>>> its historical behaviour. Any change that doesn't change the man page would
>>>> be more broken.
>>>
>>> What, it would actually copy special files now? That seems to
>>> be a good thing.
>>
>> No, it would be incompatible.
>
> How exactly. That is what I'm not getting. It will still do
> a recursive copy. Scripts using -r should still work as before.
No, they would start copying symlinks instead of following symlinks,
and the might hang on special files, etc.
> But how would this be any different from when POSIX does remove
> -r as planned? Would we wait for everyone else to catch up
> before removing the option? Or just leave it for another several
> years?
When -r is removed, anything that uses it will break, but if its
behaviour is changed, anything that uses it may silently do the
wrong thing.
>>>>> The -r option fails (actually hangs) when trying to copy a fifo
>>>>> file within a directory. It does this on both CURRENT,
>>>>> STABLE and SunOS 5.9.
>>>>
>>>> This is the documented behaviour.
>>>
>>> No, this is not the documented behavior. If this was the truth,
>>> the documenation would say:
>>
>> No, the documented behaviour is that the copy is done incorrectly.
>> Giving more details would be like documenting undefined behaviour.
>
> Giving more details on what really happens is bad? I'd like to
> know that the process might be sleeping rather than seeming to
> have hung or perhaps copying forever.
Yes, generally giving too many implementation details is bad, because
it restricts the implementation by forcing it to implement those
details "forever". This is not so bad if implementation details
are clearly marked as such.
>>>> -r is historical. POSIX permits it to be implementation-defined
>>>> to prevent breaking it.
>>>
>>> And we won't be breaking it. We won't be bringing it back.
>>> We're only going to remove it's functionality and let it work
>>> as if to be -R.
>>
>> Changing it is the same as breaking it, since its purpose is to
>> be (backwards) compatible.
>
> In many ways, it will be. I've enjoyed this conversation but
> for such a small patch, I doubt the energy exists to continue
> much beyond another email or two. :(
Here are some more quotes from POSIX.1-200x-draft7:
%%%
10486 APPLICATION USAGE
10487 The difference between -R and -r is in the treatment by cp of file types other than regular and
10488 directory. The original -r flag, for historic reasons, does not handle special files any differently
10489 from regular files, but always reads the file and copies its contents. This has obvious problems in
10490 the presence of special file types; for example, character devices, FIFOs, and sockets. The -R
10491 option is intended to recreate the file hierarchy and the -r option supports historical practice. It
10492 was anticipated that a future version of this volume of IEEE Std 1003.1-200x would deprecate
10493 the -r option, and for that reason, there has been no attempt to fix its behavior with respect to
10494 FIFOs or other file types where copying the file is clearly wrong. However, some
10495 implementations support -r with the same abilities as the -R defined in this volume of
10496 IEEE Std 1003.1-200x. To accommodate them as well as systems that do not, the differences
10497 between -r and -R are implementation-defined. Implementations may make them identical.
10498 The -r option is now marked obsolescent.
...
10531 The -r option is historical practice on BSD and BSD-derived systems, copying file hierarchies as
10532 opposed to single files. This functionality is used heavily in historical applications, and its loss
10533 would significantly decrease consensus. The -R option was added as a close synonym to the -r
10534 option, selected for consistency with all other options in this volume of IEEE Std 1003.1-200x
10535 that do recursive directory descent.
%%%
POSIX introduced the -R flag because fixing the -r flag was too hard because
the fixed version would be incompatible on thos systems that already had
the -r flag (which are primarily BSD systems according to the rationale).
Your change is only correct if:
- fixing the -r flag is no longer too hard on FreeBSD systems, and
- fixing it won't make untangling the flags harder.
Bruce
More information about the freebsd-standards
mailing list