This is related to #7. I understand that you don't want to change the name, but if mmv is packaged by distros that already have the other mmv, they will be forced either to make the two mutually exclusive (which is a bad idea, as the two programs are quite different), or to pick a new name for your mmv. Therefore, it would be a good idea to signal which alternative name you consider "standard", so that different distros are likely to pick the same alternative name.

Suggestions: mmved, mmve, mmvgo. The first two incorporating the idea of editing, the last is a pun on the implementation and the fact that the workflow is kind of "mmv-and-go!". Also, of course multi-mv, as mentioned in your README.md, but this does not distinguish the operation of this program from the other.

Thanks for mmv! I am in fact the maintainer of the other mmv, and I studied the design of your mmv while trying to work out how to fix the problems in the other mmv's edit-and-rename mode. Indeed, one option is for me to say in the man page "if you want interactive operation, use the other mmv". But as you can see, it would be nice then to have an alternative name, rather than make it hard for users to install both in parallel.

Firstly, thanks for a great idea! I really like the idea of this command and I'll probably end up using it quite a bit.
One use case I thought for it was for rearranging entire directory hierarchies, e.g. mmv $(find .)

However, it doesn't seem to understand that moving a directory also moves the contents of that directory, including
possible sources of the rename operation.

Here's a demonstration of this issue, scripted using the testscript command:

env EDITOR=$WORK/mmv-script-edit
chmod 755 $EDITOR
exec cp -r d orig
exec mmv d/a d/b d/b/a d/a/c d/a/b
cmp d/b/untouched orig/a/untouched
cmp d/a/untouched orig/b/untouched
cmp d/a/a orig/b/a
cmp d/d/c orig/d/a/c
cmp d/c/c orig/d/a/b
-- mmv-script-edit --
#!/bin/sh
cp script $1
-- script --
d/b
d/a
d/a/a
d/d/c
d/c/c
-- d/a/untouched --
a-untouched
-- d/b/untouched
b-untouched
-- d/b/a --
b-a
-- d/a/c --
a-c
-- d/a/b --
a-b

Running this script generates a sequence of renames like this:

[{d/b d/5577006791947779410} {d/a d/b} {d/5577006791947779410 d/a} {d/b/a d/a/a} {d/a/c d/d/c} {d/a/b d/c/c}]

The fourth rename of d/b/a to d/a/a fails because d/b has previously been renamed to d/a.

The mmv algorithm needs to be somewhat more sophisticated. On the positive side, fixing this will make mmv into an even more indispensable command!

Sorry about this, I should have searched for a second before releasing. Deciding command names are hard. Long names are hard to memorize, space for short names are limited and easily conflict. I understand there might be some problem for those who want to use the both tools. I really like the name and I don't think I want to change the name.

When we try to rename the files in an empty folder with mmv *, we get a file with a single asterisk as content instead of an empty file.

i would like to be abole to use find or any other command that generates a file list along with mmv, for example:

find . -type f -name "what*ever" | mmv

using xargs mmv works, but i don't think this is ideal as it might run into problems with spaces in file names, and also xargs doesn't exist on windows (i think?)

thanks - and thanks for this great program!

So if someone typed mmv it would open up all the files in the directory to be renamed.

I love this tool, could never get used to most cli file managers and this is a feature a lot of them have that I like.

What i actually tried to accomplish is simply to lowercase all (only) files. And without recursion if possible.
But i notice some strange behavior for folders?
Suse seems to crash the second run.
Alpine seems to fail (exit code 2) but it actually does not have to rename anything the second run.

Suse:

test@linux-5q3o:~/TEMP/mmv> mmv --version
mmv 2.3

Copyright (c) 2022 Reuben Thomas [email protected]
Copyright (c) 1990 Vladimir Lanin.
Licence GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

test@linux-5q3o:/TEMP/mmv> mkdir FOLDER
test@linux-5q3o:/TEMP/mmv> mmv -vt "*" "#l1"
FOLDER -> folder : done

test@linux-5q3o:~/TEMP/mmv> mmv -vt "*" "#l1"
*** buffer overflow detected ***: terminated
Aborted (core dumped)

Alpine

/tmp $ mmv --version
mmv 2.3

Copyright (c) 2022 Reuben Thomas [email protected]
Copyright (c) 1990 Vladimir Lanin.
Licence GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

/tmp $ mkdir FOLDER
/tmp $ mmv -vt "*" "#l1"
FOLDER -> folder : done

/tmp $ mmv -vt "*" "#l1"
folder -> folder/folder has failed.
The following left undone:
folder -> folder/folder

What do you think about this suggestion? It still has your origin name plus neo which says it's different, new and also differentiate it from the original tool mmv. So the conflicts should be NULL. 😉

Else, I really like this tool.

When setting $EDITOR to C:\Program Files\Microsoft VS Code\Code.exe, I get this:

C:\Users\user\Downloads\mmv_v0.1.4_windows_amd64>mmv *
mmv: abort renames: exec: "C:\\Program": file does not exist

(Regarding VS Code, I should note that "C:\Progra1\Micros1\Code.exe" works, but Code apparently "detatches" the newly created process if there's already an instance open. Doesn't appear to happen on Linux, but I suppose this is a problem with VS Code)

How to reproduce

1. Create some files that you could track by content

/tmp/test ❯ for i in $(seq 1 4); do echo $i > "test_$i.txt"; done

/tmp/test ❯ ls
test_1.txt  test_2.txt  test_3.txt  test_4.txt

/tmp/test ❯ cat test_1.txt
1

2. Move test_1.txt -> test_3.txt and test_2.txt -> test_4.txt

/tmp/test ❯ mmv test_1.txt test_2.txt

3. Notice, original 3 and 4 .txt are gone without any warning, replaced by 1 and 2

/tmp/test took 9s ❯ ls
test_3.txt  test_4.txt

/tmp/test ❯ cat test_3.txt
1

/tmp/test ❯ cat test_4.txt
2

/tmp/test ❯

I think expected behavior here is for mmv to abort rename to prevent unintended data loss, or e.g. -f flag if overwrite is truly expected and desired.

It would be great to be able to invoke mmv --git to perform git mv instead of traditional renaming.

Using git mv and git mv --dry-run if specified?

In short, dry run option is no suitable for this tool. After executing foo something -dry-run, the user expect the real execution by foo something. However, mmv always requires the user to edit the file names and it can't expect the same changes. The user have to remember the way they edit the file names so it is not that useful. If it should save the renames on dry run to somewhere, it is too complex.

I have trouble relinking multiple symlinks after the destination locations change. In order to correct these symlinks, I have to recreate them one by one. I want to use mmv as a helper for this task. Do you have any suggestion.

https://github.com/thameera/vimv