I was reminded yet again how terribly non intuitive the core file-system commands are for end user on the command line. Maybe having Rust implementations readily available would allow people to fork them and improve the interface in some new shell+utils combo package.
(rm, cp require -r, mv doesn’t, no auto-directory creation for mv - if you don’t believe me look at git/hg which don’t copy the semantics + I’d like reliable dry run and by default confirm every destructive action)
> rm, cp require -r, mv doesn’t, no auto-directory creation for mv
These are all like that on purpose.
mv doesn't have -r because it's a safety feature for rm and cp, since deleting or copying an entire directory is expensive so you should have to specify it explicitly. Moving a directory is really just renaming it, which isn't expensive when it's on the same filesystem (and it usually is).
The most common case for the destination directory not existing when moving something is a typo in the path. Then you'd end up creating a directory you didn't intend to, possibly on a filesystem you didn't intend to, and moving all the other arguments over there. It could be useful to make it possible to explicitly specify that you want this, similar to mkdir -p, but you could add that to the existing mv without breaking anything.
Deleting entire directories by accident is expensive in more than computing resources.
And copying them is still actually expensive. Data expands to consume all available space. Accidentally copy a 16TB directory structure and you're going to max out the I/O on your machine for hours and maybe run it out of space. It's not a big ask to type two characters to confirm that you want to do that.
(rm, cp require -r, mv doesn’t, no auto-directory creation for mv - if you don’t believe me look at git/hg which don’t copy the semantics + I’d like reliable dry run and by default confirm every destructive action)