'File | Rename Special" - want options on extension

[Papoulka]

I've bumped this and broadened the title because there are more 'File | Rename Special' cases where it applies, and to consolidate another request. Overall I ask:

---> For 'RegExpRename', 'Search & Replace', and 'Edit Item Names' please add the options to omit or include the file extensions.

At present these are inconsistent. S&R include the extension whereas Edit and RegExp do not. However, there are times in all three where the option is important.

For example I want RegExp Rename to add characters at the end of the filename. But the standard regex positioner '$' adds them to the extension. Scripting is possible of course but it would really be nice if I could just checkmark "ignore extension" or uncheck "include extension".

Thanks

[Garonne]

I don't think that's necessary as the current behavior is standard for Regexps. If you want to add something before the last period it is easy enough to solve with a simple Regexp (If you are using Regexps you should be able to come up with a regex to add something at the right place easily, if not you better stick to normal S&R anyways). No need to add another check-box somewhere.

[Papoulka]

Example: I need a regex to examine these files and add an underscore to the end of each filename that has "keep":

_52 keep_(2).jpg
settle.keep.23-002.gif
standard.view_x001 100.3.png
standard.view_keep 100.4.3.tga

[Marco]

Code: Select all

(.*keep.*)\.(.*?)$ > $1_.$2

But I agree with you Papoulka, an option to leave extensions alone is greatly appreciated here, at least for the Edit Items Names function - this is something that could really save me some extra work when needed (btw, I wished this months ago, http://www.xyplorer.com/xyfc/viewtopic. ... tems+names).

[Papoulka]

Thank you, Marco - that works great. I couldn't figure out how to capture the first string correctly, with the multiple '.' in the filenames. I'll be putting this to use now.

[Papoulka]

... And my request still stands. Regex can handle filenames and extensions BUT being able to ignore the extension is a big help. That leverages the power of the file manager (knowing which is name and which is extension) to make writing the regex easier. It also focuses on 90% of the use cases, when we want to keep the extension unchanged. Two plusses; no minus.

[Marco]

+1

[admin]

Looks good. Currently no time though.

[admin]

The only problem here is syntax.

In Batch Rename "/e" works well as a switch.

In Search & Replace I cannot use it because "/" is an operator. At least it would be confusing.

In RegExp replace I'm not sure if "/" could appear in a pattern.

[Marco]

Why not a checkbox?

[admin]

Because I want the complete job in a string. Better for MRU, for scripting, for sharing.

[TheQwerty]

The only problem here is syntax.

In Batch Rename "/e" works well as a switch.

In Search & Replace I cannot use it because "/" is an operator. At least it would be confusing.

In RegExp replace I'm not sure if "/" could appear in a pattern.

Some quick tests seem to reveal it's all rather confusing already.

Given:
.\a\
.\file.txt
.\file-01.txt
And expecting only Batch Rename to use '/e' for modifying extension behavior.

1) The rename specials available via the Rename SC don't seem to obey Preview All and Configuration | Preview | Rename preview | Preview all Rename Special operations when called via the menu.

2) Batch Rename does not allow moving on rename:

Code: Select all

::rename 'b', 'a\e*';
"Invalid Pattern"
Expected
.\a\efile.txt
.\a\efile-01.txt
(or error if Configuration | Sort and Rename | Rename | Allow move on rename is disabled)

3) Batch Rename is too aggressive in using '/e' as drop extension:

Code: Select all

::rename 'b', 'a/e*';
.\a\
.\a-01
.\a-02
Expected:
.\a\efile.txt
.\a\efile-01.txt
(or error if Configuration | Sort and Rename | Rename | Allow move on rename is disabled)

4) Regex Rename puts the list in an incorrect state:

Code: Select all

::rename 'r', '^ > a\e';
.\a\
.\a\efile.txt
.\a\efile-01.txt
Works as expected except the list literally shows them as 'a\efile*' until refreshed.
Similarly for:
::rename 'r', '^ > a/e';
::rename 'r', '^ > \e';
::rename 'r', '^ > /e';

5) Regex Rename reacts differently for each item, puts the list in an incorrect state, and creates empty folders (not covered by Undo)

Code: Select all

::rename 'r', '^ > b\e';
"Rename Failed. An item could not be renamed. The following item could not be renamed: '.\file.txt'
Error: The system cannot find the path specified."
After OK:
.\a\
.\b\
.\file.txt
.\b\efile-01.txt (literally shown this way until list refresh)
After Cancel:
.\a\
.\b\
.\file.txt
.\file-01.txt
Expected:
.\a\
.\b\efile.txt
.\b\efile-01.txt
(or error if Configuration | Sort and Rename | Rename | Allow move on rename is disabled)
In very least cancel should not create '.\b\' and OK should fail for both.
Similarly for:
::rename 'r', '^ > b/e';

6) S&R doesn't allow moving:

Code: Select all

::rename 's', 'f/a\e';
"Bad Filename - This is not a valid filename: 'a\e'"
Expected:
.\a\eile.txt
.\a\eile-01.txt
(or error if Configuration | Sort and Rename | Rename | Allow move on rename is disabled)
Similarly for:
::rename 's', 'f/a/e';
::rename 's', 'f>a\e';
::rename 's', 'f>a/e';

To me the problem is should these support moving? If so then '/' and '\' should be seen as directory separators complicating things further.
Is it enough that if the pattern ends with '/e' it can be considered a flag? Since it seems unrealistic to believe someone is actually wanting to use to move items to a folder and then rename them all to 'e'.

Though that still leaves problems with S&R's separator-less remove and users that decide to tweak the Regex separator to contain '/'.

What if a new pattern was introduced, perhaps ' ::flags', and anchored to the end?
I'd also recommend adding 'c' as a flag for case-sensitivity as a replacement for the existing '\'.
Then the old syntax could be deprecated and eventually put out to pasture.

[admin]

OK, I flagged this post for future read. Looks like a biggie.

[admin]

1) This is by design.

2) etc. Moving is not supported here, and not planned.

The RegExp issue I will look at later.

[Stefan]

Maybe introduce an own tag like [XY:flag] as part of the operation string.

[XY:flag] is allowed only at begin of line and is removed before actual string manipulation.

flag:
    b : work on base only
    e : work on extension only
    c : case sensitive

Example:
[XY:bc](.*keep.*) > $1_


XYplorer will read the flags 'bc' and set the option,
then the tag '[XY:bc]' is removed from the string
and the normal renaming will be processed.