If the folder name contains ., then %O the name obtained is wrong

[yahuu]

For example, the folder name is: 2023.09.08
The value obtained by %O is: 2023.09

[ghisler(Author)]

This isn't a bug, just a question of definition. Currently the part of the name behind the last dot is put in %E, while the part before it is put in %O. This is done both for files and folders.

The multi-rename tool behaves the same, but there is a placeholder to change this behaviour:
[I] Ignore dots in folder names from this point forward, so [N] contains the entire folder name, and [E] is empty (no influence on files).
If inserted again, don't ignore dots in folder names any more from that point forward.

Such a change would also be useful for command line parameters. Then %E would always be empty for folders.

[yahuu]

This isn't a bug, just a question of definition. Currently the part of the name behind the last dot is put in %E, while the part before it is put in %O. This is done both for files and folders.

The multi-rename tool behaves the same, but there is a placeholder to change this behaviour:
Ignore dots in folder names from this point forward, so [N] contains the entire folder name, and [E] is empty (no influence on files).
If inserted again, don't ignore dots in folder names any more from that point forward.

Such a change would also be useful for command line parameters. Then %E would always be empty for folders.

I am not using this parameter in multi-rename but in usercmd.
Can TC achieve this: when the object is a folder, %O is the full name, when the object is a file,%O is the name without extension.

[yahuu]

Folders should not have extensions, so it makes sense that the %E of the folder would be empty.
The problem now is that when I zip the folder using the bandizip command line, the resulting zip file is not named as I would expect.

[ghisler(Author)]

Moderator message

Moved to suggestions