ismaelgv / rnr

A command-line tool to batch rename files and directories
MIT License
474 stars 15 forks source link

Issue with regex and capture groups #42

Closed nk9 closed 3 months ago

nk9 commented 3 months ago

I am not sure if I'm doing something wrong here, but I'm trying to do this:

Statement_022024_1234.pdf->Statement_20240220_5678.pdf

But this command isn't doing what I expect:

rnr "_(\d\d)(\d\d)(\d\d)_1234" "_20${3}${2}${1}_5678" Statement_*

Instead, the dry run tells me that the command will do this:

Statement_022024_1234.pdf->Statement_20_5678.pdf

Is this a bug in rnr? I've just downloaded it, rnr 0.4.2

ismaelgv commented 3 months ago

I think that the problem is that you are using double quotes ("). In most shells, these strings will interpolate the environmental variables and other expansions (e.g. wildcard *).

Try to use literal string with single quotes (').

nk9 commented 3 months ago

That's totally it, and I see that there's even a note in the README about it. 😊 Thanks for the quick answer!

What do you think about providing a warning in the output (at least for the dry run environment) when the user attempts to interpolate a variable that doesn't exist?

UPDATE: Oh, I see: this wouldn't work, because by the time the argument gets to rnr, the variable has already been removed by the shell. Hmm. What about supporting the \1 style of capture group references, and using that in the docs first? That way the most common usecase could avoid this issue entirely?

ismaelgv commented 3 months ago

I'm glad that fixed your problem. 👍

However, I am not sure if is worth it to add complexity to the tool just to show these kind of warnings. I may take a look and make a decision.

nk9 commented 3 months ago

Just thinking aloud here: it would actually still be possible to provide a useful warning if the condition was that the EXPRESSION pattern contains a different number of capture groups than are inserted in the REPLACEMENT pattern.

ismaelgv commented 3 months ago

Yeah, I was thinking in that but I have to analyze some corner cases that may appear with these changes.

For example, the number of capture groups must be extracted first to be analyzed. Also, the capture groups in the replacement may appear repeated several times. It would need to find exactly that appear one or more times. Not sure if it worth the effort for little benefit.

I will take a look when I find some free time to explore the problem.

I will close the issue since the original problem is solved. Do not hesitate to report any bugs you may find.

nk9 commented 3 months ago

Alright, thanks for your time and for the excellent OSS tool!