It always seemed like the recursive flag of cp was an implementation detail leaking into the UI. Like, I get that copying a file requires creating more than one inode, but...so? Eventually, graphical OSes agree with me—copy/paste works the same on folders as it does on files.
It's rather sad that none of the answers were that the cp command simply did not gain a recursive option until the 1980s, well into the 1980s if you were on one side of the Unix wars.
Yes, seriously. When you read about the supposed evils of cat -v from the Unix nostalgia people, remember that it was the same people who gave cat its -v option who also gave cp its -r option, in 4.2BSD.
It took over half a decade to percolate out of the BSD world, too. AT&T Unix System 5 did not have an -r option to cp. Here's Brandon S. Allbery explaining in 1987 how one copies directories on AT&T Unix System 5 Releases 2/3 by combining find and cpio -p:
> When you read about the supposed evils of cat -v from the Unix nostalgia people, remember that it was the same people who gave cat its -v option who also gave cp its -r option, in 4.2BSD.
Then the people who complained about cat -v went ahead and made better Unix, called Plan 9, in which moving (as opposed to merely renaming) a directory is impossible: instead, you're supposed to do mkdir && dircp && rm -r. Which is quite a choice, if I say so myself: there is simply no low-level primitive (syscall or 9p message) for moving files across directories, even on the same file server. Their version of mv can move files across the directories, but it's still done with internal equivalent of cp+rm.
They also ignored what was happening with C outside Bell Labs, and thus the Plan 9 C compiler is rather special versus a ISO C compiler of the time, in how files are organised and available features.
Afterwards they made a better Plan 9, called Inferno, with a safer userspace programming language, leaving their C creation only for kernel code, and DisVM implementation.
drhagen · · focus · HN ↗
dotancohen · · focus · HN ↗
<a href="https://unix.stackexchange.com/questions/82485/when-wouldnt-one-want-cp-to-be-recursive" rel="nofollow">https://unix.stackexchange.com/questions/82485/when-wouldnt-...
It seems that recursive by default would have been much more intuitive.
JdeBP · · focus · HN ↗
Yes, seriously. When you read about the supposed evils of cat -v from the Unix nostalgia people, remember that it was the same people who gave cat its -v option who also gave cp its -r option, in 4.2BSD.
It took over half a decade to percolate out of the BSD world, too. AT&T Unix System 5 did not have an -r option to cp. Here's Brandon S. Allbery explaining in 1987 how one copies directories on AT&T Unix System 5 Releases 2/3 by combining find and cpio -p:
* <a href="https://groups.google.com/g/comp.unix.questions/c/XiumTgkcYRE/m/kJwkU5SlOasJ" rel="nofollow">https://groups.google.com/g/comp.unix.questions/c/XiumTgkcYR...
Originally we read directories as raw byte streams and liked it, you know. (-:
Joker_vD · · focus · HN ↗
Then the people who complained about cat -v went ahead and made better Unix, called Plan 9, in which moving (as opposed to merely renaming) a directory is impossible: instead, you're supposed to do mkdir && dircp && rm -r. Which is quite a choice, if I say so myself: there is simply no low-level primitive (syscall or 9p message) for moving files across directories, even on the same file server. Their version of mv can move files across the directories, but it's still done with internal equivalent of cp+rm.
pjmlp · · focus · HN ↗
Afterwards they made a better Plan 9, called Inferno, with a safer userspace programming language, leaving their C creation only for kernel code, and DisVM implementation.