And, see, the Linux behavior is what I'd expect. If I ask for a directory itself to be copied, I name only the directory. If I want it unpacked, I glob it as such:
cp -R source_directory/* destination_directory/
(Yeah, okay, I use globs instead of . Same diff in this case.)
Copy really needs to always behave as "I want this thing in that place". The BSD way is actually more surprising when you least expect it...and the surprise (unpacking the files) is more dangerous than if Linux's behavior surprises you! Just consider this...
Well, crud. On Mac, now you have just crammed a bunch of garble-named photos into an already crowded folder, and lost the one thing that you had going for you: the containment of the source directory. That's non-trivial to undo. Meanwhile, on Linux, you can find pictures_to_sort/my_vacation_pics_with_lousy_names/ and go from there. Much better.
Yet the reverse surprise, not unpacking when you expect it to, is easily remedied with a single command.
Surprises are bad, hard-to-undo surprises even more so.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Something I mentioned in a different comment, rsync behaves the way cp does on a Mac. So for people used to rsync, it's not a surprise, and GNU cp is the surprise!
I think it's telling though that there are so many articles about rsync warning you you can screw up if you don't get the slashes right - the majority of people over the last couple of decades have been used to doing it the GNU way.
There's also a reason rsync behaves that way, and it too is something I'd expect. You syncsource-directory to destination-directory. As with any other form of syncing, it would be expected that you'd have two folders which are made to match one another.
"Copy X to Y", find X in Y.
"Sync X and Y", find X and Y are identical.
One thing that makes GNU cp a surprise is the inconsistent behavior of cp -R . ../foo, the source is clearly a directory, however, this time the contents are copied.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
And, see, the Linux behavior is what I'd expect. If I ask for a directory itself to be copied, I name only the directory. If I want it unpacked, I glob it as such:
(Yeah, okay, I use globs instead of
.Same diff in this case.)Copy really needs to always behave as "I want this thing in that place". The BSD way is actually more surprising when you least expect it...and the surprise (unpacking the files) is more dangerous than if Linux's behavior surprises you! Just consider this...
Well, crud. On Mac, now you have just crammed a bunch of garble-named photos into an already crowded folder, and lost the one thing that you had going for you: the containment of the source directory. That's non-trivial to undo. Meanwhile, on Linux, you can find
pictures_to_sort/my_vacation_pics_with_lousy_names/and go from there. Much better.Yet the reverse surprise, not unpacking when you expect it to, is easily remedied with a single command.
Surprises are bad, hard-to-undo surprises even more so.
Something I mentioned in a different comment,
rsyncbehaves the waycpdoes on a Mac. So for people used to rsync, it's not a surprise, and GNUcpis the surprise!I think it's telling though that there are so many articles about rsync warning you you can screw up if you don't get the slashes right - the majority of people over the last couple of decades have been used to doing it the GNU way.
There's also a reason rsync behaves that way, and it too is something I'd expect. You sync
source-directorytodestination-directory. As with any other form of syncing, it would be expected that you'd have two folders which are made to match one another."Copy X to Y", find X in Y.
"Sync X and Y", find X and Y are identical.
Simple.
One thing that makes GNU
cpa surprise is the inconsistent behavior ofcp -R . ../foo, the source is clearly a directory, however, this time the contents are copied.