Re: [Bug 154602] Re: incorrect cp(1) behaviour upon "mkdir foo; cp -r foo foo"
Jens Ropers wrote: > 2009/3/30 jaduncan : >> 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 ;-) >> 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 154602] Re: incorrect cp(1) behaviour upon "mkdir foo; cp -r foo foo"
Jim Meyering writes: > I'm confident that POSIX does not require > cp -r dir dir to create dir/dir ;-) That's certainly true: an implementation is clearly allowed to (but not required to) report an error and exit without doing anything when it sees this example. However, that's not what GNU cp does, which raises the issue. As near as I can figure out, this is a hole in POSIX. It nowhere specifies what "cp" should do when inputs and outputs overlap, which they can in even-more-interesting ways than "cp -R dir dir". Perhaps this should be raised with the POSIX folks, but in the meantime I don't see that GNU cp needs to change as far as conformance goes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
