> nobody™ still runs coreutils from 24 years ago.
Sprite 2.077 pc386
Welcome to Sprite
root@cherimoya [1] # cp --version
GNU fileutils 3.9
root@cherimoya [2] # cp --help | grep recurs
-r copy recursively, non-directories as files
-R, --recursive copy directories recursively
root@cherimoya [3] #
I'll take the honorary title of nobody ;-)-a
Not sure why you wouldn't want to preserve timestamps, links, etc. by default.
I really wish there was a way to know if LLMs hallucinate these switches incorrectly, like I do.
Feels like this would be exactly the kind of thing they would get wrong. Fur exactly, the training set isn't trained to know the context of execution (FreeBSD vs macos vs Linux), right?
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.
This always get me. I instinctively -r, until chown which of course doesn’t take it.
I'm more inclined to use the uppercase -R as it's standardized by POSIX and will generally behave the same on any POSIX compliant system.
On a somewhat related note, I really hate that in scp -r and -R mean entirely different things.
would you be safe in using --recursive always? (e.g. shell scripts)
[dead]
This blog post is odd because it keeps on hinting about a difference between `-r' and `-R' and links to the source code but never actually says what it is. I'll quote the OpenBSD manual that the post mentions but does not link to for some reason:
> Historic versions of the cp utility had an -r option. This implementation supports that option; however, its use is strongly discouraged, as it does not correctly copy special files, symbolic links or FIFOs.
https://man.openbsd.org/cp