alt Hacker Newscp: -r or -R?
Comments
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.
> 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] #
Kind of off topic, but why in the world in 2026 do POSIX utilities still rely on global variables to pass around state? Is it too complicated to pass around a struct address in C or something?
-a
Not sure why you wouldn't want to preserve timestamps, links, etc. by default.
-h perhaps the only useful comment here. -R just looks baroque, but ls(1) might think it fine. I once read an article about the inconsistencies in *nix CLI commands, but the picture's much better than hot-key and shortcut conflicts- <which get silently absorbed by whatever's running, no way to tell what they might've done or where they went..> I hestitate to consult documentation, because of course there is non anymore. Why not Google 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.
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.
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?
This always get me. I instinctively -r, until chown which of course doesn’t take it.
On a somewhat related note, I really hate that in scp -r and -R mean entirely different things.
or -a?
would you be safe in using --recursive always? (e.g. shell scripts)
[dead]
there there are antisocial surprises, like YC's 'login' required after writing a post - which led me to go log into another machine, check my list, then come back here and login. Looming is the question whether a login failure would've erased what I wrote. There are of course fantasticaly more egregious UX gaffes.. imagining now [cp] and [ls] buttons .. perhaps better than 'intelligent' locator select/copy/paste madddenlingly split between kb keys and screen touches, highlighting not exactly what precisely you specify, instead crazily jumpping the selection about phrenically, while necessity of scrolling offscreen up and down further complicates - often 'select all' means 'select only whats onscreen' <surprise later, only after a paste> micro displays, big thumbs, filly 5/8ths of my present Android screen obscured by an on-screen keyboaard, even though I'm typing on a BT kb. As you might infer from this rambling paragraph I'm an OOtB ADHD wannabe-Dev type, enough at least to have heard about 'DNRY' which in sum, I'd say I hope Ai somehow obliterates <after the fashion of *nix apt's, perhaps?> with 'you can you it anyway you like - there are a dozen ways to do anything, and they all work all the time - modulo of course in reality that anti-DNRY paridigm taken beyond the UI foments chaos and confusion.
The POSIX standard does not appear to support -r lowercase (so don't use it!):
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/
Edit: adjusted to the latest version of the standard.