2009/3/31 C de-Avillez <[email protected]>: > Interesting. Jim Meyring's answer did not make it here (although, > AFAICS, it was correctly addressed). So, here it is: > > Jens Ropers wrote: >> 2009/3/30 jaduncan <[email protected]>: >>> This is correct behaviour as per POSIX - it's how it should work! >> >> Says who? > > I'm confident that POSIX does not require > cp -r dir dir to create dir/dir ;-)
Just to clarify again, what bothers me about this is that cp says that is can't copy a directory into itself *and then does it anyway, once*. [I.] If it said that it can't do it and then didn't do it, that would be fine. [II.] If it accepted the recursive directory copying command and tried to execute it until it errored out because the path got too long, that would be fine as well. Possibly a bit crude, but better than the current inconsistency between what it says it can't do and what it still does. I tried this on OpenBSD 4.3 for comparison purposes: Unlike GNU's coreutils cp(1), OpenBSD's cp(1) --which is derived from AT&T UNIX Version 1-- expressly says on its man page that it is POSIX-compliant: http://www.openbsd.org/cgi-bin/man.cgi?query=cp OpenBSD's cp(1) behaves as described under [II.]: It recursively copies foo into itself until the path becomes too long, at which stage it produces an error message and stops copying any further. This produces a long subtree of foo/foo/foo/foo... and so forth, and the testfile is also present at each level. Again, this may seem more bare-bones, as it doesn't attempt to catch attempts at recursive copying beforehand, but it's actually more consistent and more logical and doesn't do anything it said it couldn't do. So apologies if I'm being impolite, but I'm more inclined to believe that OpenBSD's cp(1) really is POSIX-compliant --as its man page says it is-- than I am inclined to believe jaduncan's claim that GNU coreutils cp(1) was POSIX-compliant. Of course it's also possible that POSIX doesn't specify at all how cp(1) should behave in this case. But that too would only invalidate jaduncan's citation of POSIX compliance in his objection. And yes, I absolutely believe that it makes good sense to keep this open as a tracking bug here, and to take it up with upstream. And --apologies again-- but I'm sceptical of the declaration that the GNU project would not want to change this; asking won't hurt. Thanks and regards, --ropers >>> This is something that would be an upstream bug, but they will not want >>> to change this behaviour. >> >> Well, have you asked them? > > I don't like the existing behavior, but this is a rather hairy corner of > copy.c already, and considering we're talking about the state left after > the user runs a bogus command (which is surprisingly hard to detect _in > general_), I'm in no big hurry to fix it. > > However, if someone sends in a perfect patch, > > http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING > > I'll be very interested. -- incorrect cp(1) behaviour upon "mkdir foo; cp -r foo foo" https://bugs.launchpad.net/bugs/154602 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
