Hacker News Reader

Comment by magicalist | Hacker News Reader

> If the destination doesn't exist, `move` renames the source file to the destination name in the current directory. This behavior is documented in Microsoft's official move command documentation[1].

> For example: `move somefile.txt ..\anuraag_xyz_project` would create a file named `anuraag_xyz_project` (no extension) in the current folder, overwriting any existing file with that name.

Can anyone with windows scripting experience confirm this? Notably the linked documentation does not seem to say that anywhere (dangers of having what reads like ChatGPT write your post mortem too...)

Seems like a terrible default and my instinct is that it's unlikely to be true, but maybe it is and there are historical reasons for that behavior?

[1] https://learn.microsoft.com/en-us/windows-server/administrat...

View on HN

The move command prompts for confirmation by default before overwriting an existing file, but not when invoked from a batch file (unless /-Y is specified). The AI agent may be executing commands by way of a batch file.

However, the blog post is incorrect in claiming that

  move * "..\anuraag_xyz project"

would overwrite the same file repeatedly. Instead, move in that case aborts with "Cannot move multiple files to a single file".

First, I think there's a typo. It should be:

> 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...

But it will show a warning. I don't get the issue.

   D:\3\test\a>move 1 ..\1
   Overwrite D:\3\test\1? (Yes/No/All):

If anything, it's better than Linux where it will do this silently.

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)

tinycorelinux aliases cp and mv to include -i which is nice.

I've actually read that Microsoft documentation page you and the OP linked to and nowhere does it describe that behaviour.

That's basically what linux `mv` does too. It both moves files to new directories and renames files.

mkdir some_dir mv file.txt some_dir # Put file.txt into the directory

mv other_file.txt new_name.txt # rename other_file.txt to new_name.txt

Linux's mv does not have this particular failure mode.

  $ touch a b c
  $ mv a b c
  mv: target 'c': Not a directory

That's not what OP encountered. The "failure" mode is

    mv file ../folder

where folder is not a folder (non-exist, or is a file).

And Linux will happily do this too.

  $ mkdir -p /tmp/x/y/z
  $ cd /tmp/x/y/z
  $ touch a b c
  $ mv a b c ../notexist
  mv: target '../notexist': No such file or directory

Do it with one file?

$ mv a ../notexist

$ echo $?

That's not what OP encountered.

> When Gemini executed move * "..\anuraag_xyz project", the wildcard was expanded and each file was individually "moved" (renamed) to anuraag_xyz project within the original directory.

> Each subsequent move overwrited the previous one, leaving only the last moved item

In a different scenario where there was only one file, the command would have moved only that one file, and no data would have been lost.

Dunno about Windows, but that's how the Linux `mv` works.

Reply on news.ycombinator.com