> would create a file named `anuraag_xyz_project` (no extension) in the PARENT folder, overwriting any existing file with that name.
But that's how Linux works. It's because mv is both for moving and renaming. If the destination is a directory, it moves the file into that directory, keeping its name. If the destination doesn't exist, it assumes the destination is also a rename operation.
And yes, it's atrocious design by today's standards. Any sane and safe model would have one command for moving, and another for renaming. Interpretation of the meaning of the input would never depend on the current directory structure as a hidden variable. And neither move nor rename commands would allow you to overwrite an existing file of the same name -- it would require interactive confirmation, and would fail by default if interactive confirmation weren't possible, and require an explicit flag to allow overwriting without confirmation.
But I guess people don't seem to care? I've never come across an "mv command considered harmful" essay. Maybe it's time for somebody to write one...
Interestingly, there's no reason for this to be the case on Windows given that it does, in fact, have a separate command (`ren`) which only renames files without moving. Indeed, `ren` has been around since DOS 1.0, while `move` was only added in DOS 6.
Unfortunately, for whatever reason, Microsoft decided to make `move` also do renames, effectively subsuming the `ren` command.
This is what the -t option is for. -t takes the directory as an argument and never renames. It also exists as an option for cp.
And then -T always treats the target as a file.
OK yeah, I feel dumb now, as that's fairly obvious as you write it :D I think the current folder claim just broke my brain, but I believe you're right about what they meant (or what ChatGPT meant when it wrote that part).
But at least mv has some protection for the next step (which I didn't quote), move with a wildcard. When there are multiple sources, mv always requires an existing directory destination, presumably to prevent this very scenario (collapsing them all to a single file, making all but the last unrecoverable).
The current folder thing broke my brain too. I literally had to go to my terminal to make sure it didn't work that way, and confirm it was a typo. It was only after that I realized what the author meant to say...
The Linux (GNU?) version (mv) can change its behaviour according to what you want.
e.g. "mv --backup -- ./* wrong-location-that-doesnt-exist" will rename your files in an unhelpful fashion, but won't lose any.
e.g. "mv --no-clobber -- ./* wrong-location-that-doesnt-exist" won't overwrite files.
It's trivial to setup an alias so that your "mv" command will by default not overwrite files. (Personally I'd rather just be wary of those kinds of commands as I might be using a system where I haven't customised aliases)
> would create a file named `anuraag_xyz_project` (no extension) in the PARENT folder, overwriting any existing file with that name.
But that's how Linux works. It's because mv is both for moving and renaming. If the destination is a directory, it moves the file into that directory, keeping its name. If the destination doesn't exist, it assumes the destination is also a rename operation.
And yes, it's atrocious design by today's standards. Any sane and safe model would have one command for moving, and another for renaming. Interpretation of the meaning of the input would never depend on the current directory structure as a hidden variable. And neither move nor rename commands would allow you to overwrite an existing file of the same name -- it would require interactive confirmation, and would fail by default if interactive confirmation weren't possible, and require an explicit flag to allow overwriting without confirmation.
But I guess people don't seem to care? I've never come across an "mv command considered harmful" essay. Maybe it's time for somebody to write one...