Date: Sat, 2 Apr 2005 18:10:05 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Tom Rhodes <trhodes@FreeBSD.org> Cc: standards@FreeBSD.org Subject: Re: Patch for cp(1) Message-ID: <20050402175234.C1084@epsplex.bde.org> In-Reply-To: <20050401185743.607471f9@mobile.pittgoth.com> References: <20050330181904.16519571@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> <20050401185743.607471f9@mobile.pittgoth.com>
index | next in thread | previous in thread | raw e-mail
On Fri, 1 Apr 2005, Tom Rhodes wrote: > On Fri, 1 Apr 2005 20:43:02 +1000 (EST) > Bruce Evans <bde@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@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. Brucehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050402175234.C1084>