Esc* modifiers eat backslashes

[lxp]

Codes with modifiers escbackslash and escregexp seem to devour backslashes that follow them.

Here's a demo with a few renames that move a file into a folder. Inspired by this discussion.

// These work:
// Rename PATTERN=* TO="D:\test\*" IGNOREEXT
// Rename PATTERN=* TO="{dlgfolder}*" IGNOREEXT

// Rename PATTERN=(.*) TO="D:\\test\\\1" REGEXP IGNOREEXT


// So does this:

// @set target={dlgfolder|||escbackslash}
// Rename PATTERN=(.*) TO="{$target}\1" REGEXP IGNOREEXT

// ... and this:

// @set target={dlgfolder|||escregexp}
// Rename PATTERN=(.*) TO="{$target}\1" REGEXP IGNOREEXT


// But these won't:

// Rename PATTERN=(.*) TO="{dlgfolder|||escbackslash}\1" REGEXP IGNOREEXT
// Rename PATTERN=(.*) TO="{dlgfolder|||escregexp}\1" REGEXP IGNOREEXT

// ... they need to be written like this:

// Rename PATTERN=(.*) TO="{dlgfolder|||escbackslash}\\1" REGEXP IGNOREEXT
// Rename PATTERN=(.*) TO="{dlgfolder|||escregexp}\\1" REGEXP IGNOREEXT


// Normal characters are ok:

// Rename PATTERN=(.*) TO="{dlgfolder|||escbackslash}t\1" REGEXP IGNOREEXT
// Rename PATTERN=(.*) TO="{dlgfolder|||escregexp}n\1" REGEXP IGNOREEXT

[Leo]

Trying with one of the problem ones:

Rename PATTERN=(.*) TO="{dlgfolder|||escbackslash}\1" REGEXP IGNOREEXT

That works OK for me (moves the selected file into the chosen folder).

It generates a command line like this, which looks correct:

Rename PATTERN=(.*) TO="C:\\Chosen Folder\\\1" REGEXP IGNOREEXT

[lxp]

Hey, it's getting even wilder... please try again with ChosenFolder.

[Leo]

Confirmed! That is weird. It must be putting things together slightly differently if the path needs quotes or not.

We need to look into why, as the two should at least be consistent (one way or the other). I've made a note to look at it.

I would use this form:

@nofilenamequoting
Rename PATTERN=(.*) TO="{dlgfolder|||escbackslash|noterm}\\\1" REGEXP IGNOREEXT

The @nofilenamequoting seems to be optional, at least in the cases I've tested, but I'd rather be explicit about it, especially here when we're doing something delicate with escaped characters.

Adding noterm means the path won't have any backslash(es) on the end, allowing us to add the exact number we need explicitly.

The "add filename on to path" functionality doesn't know about the escbackslash (since it's outside of the {dlgfolder|...} it applies to), I would not rely on it to correctly preserve the double backslashes at the end of the escaped string when adding a component to the end of the path. We might change it so that does work in both these cases (depending on what's going on behind the scenes), but I like doing it explicitly and not relying on that at all. One less thing to worry about!

[slouw]

@Leo

The "add filename on to path" functionality doesn't know about the escbackslash (since it's outside of the {dlgfolder|...} it applies to),

@Leo is it accurate to say that External control codes only apply to that captured/defined by the curly brackets? @Ixp seemed to confirm that in the discussion referenced above but he went on to say to look "further down for an exception". It seems to me that exception is in fact the bug discussed here.
@Ixp if you see this maybe you might clarify?
Any comments appreciated as always..

[lxp]

@slouw

It seems to me that exception is in fact the bug discussed here.

Yes, indeed