[X] Suspected bug regarding matching "unclosed" string parenthesis in Regex


#1

This is a very specific issue, at least as far as I've looked into it. It could be bug that occurs across the entire program when dealing with using Regex to match strings, but I've only a attempted a function similar to the example below in the Guess Values Action.
The program will not match a single parenthesis using the wildcard "." match function that matches any character if its preceded by a single string parenthesis, or "(".

Here's what I'm talking about.
I have:
TITLE: Song ft. xyz (edit)
ARTIST: abc

I want
TITLE: Song (edit)
ARTIST: abc ft. xyz

There's a little more to it but that's the basics.

if I write my Guess Value as:

%artist% $regexp(%title%,(.*) (ft\..*) (\(.*),$2 +++ $1 $3) %artist% +++ %title%

The action will not do anything. There is no change whatsoever to the text of any of the fields of the file.

However, if I add the closing parenthesis to the third matching group,

%artist% $regexp(%title%,(.*) (ft\..*) (\(.*\)),$2 +++ $1 $3)

It some reason decides to work. While yes, it makes sense that I'm giving the function more info on what to look for, the wildcard with repeat should pick up the parenthesis anyways because its a character and the wildcard is searching for any character!

I've also attempted to instruct the function to match anything up until end of line, so:

(\(.*$)

Still no effect.

This tells me there's something internally in the program that confuses the fact that code cannot execute if parenthesis aren't closed, with an unclosed parenthesis in a string. I report this because it leaves many users libraries at risk because if they attempt any similar function, it will only match up until a closed parenthesis and anthing following will be wrongly moved or even more likely lost forever.
This is a simple bug that prevents many options in customizable metadata editing/formatting.

I've consulted with a friend who is fluent in several programming languages and is a web developer and he agrees with me on my diagnosis. I hope this post is not overlooked as a "small issue".


#2

No, I think the problem are the missing '

If you enter the original expression in the Convert>Tag-Tag function as a test enviroment:
$regexp('Song ft. xyz (edit)',(.) (ft..) ((.*),$2 +++ $1 $3)

it produces a syntax error straight away.
If you use
$regexp('Song ft. xyz (edit)','(.) (ft..) ((.*)',$2 +++ $1 $3)
on the other hand, you get a result other than a syntax error.


#3

Your problem is self inflicted, because you did not respect the rules for the Mp3tag scripting language.
On the basic scripting level, the round brackets are part of the scripting language and they are applied along with a function call to enclose the given parameter list for the called function.
Round brackets have to be devalued, when using them as literal characters.
A round bracket within a function parameter list has to be enclosed in single apostrophes, to make it a literal character, or simply enclose the entire parameter list in one pair of single apostrophes.

Maybe you can find some regex inspiration from there ... do have a closer look ...
Move "Featuring" from Artist to Title

DD.20170404.1031.CEST


#4

The same friend who felt it was a bug later sent me the below link, which does prove our assumption but however shows that this is a trait across other languages and, like you said, is part of the MP3tag scripting language and not a bug.
https://coderanch.com/mobile/t/416642/java/...enthesis-string

My examples use a backslash to devalue the round brackets, which according to the Help page is valid.

Either way I've built a work around for my issue using several different Guess Values within an Action. But definitely is not the most efficient.

I do appreciate the amazingly quick responses.


#5

I assume you speak of the help page documentation regarding the Regexp language.
Mp3tag supports its own scripting language, where the Regexp language is an embedded feature.
Therefore you have to follow the rules of Mp3tag in the first instance.
If you want to apply the opening or closing round bracket as a literal character within a Mp3tag formatstring, then you have to devalue these characters by enclosing them into single apostrophes, because the round brackets are part of the Mp3tag scripting language, containing the parameter list, on applying a function call.

See also ... Characters with special functionality ...
http://help.mp3tag.de/main_scripting.html

DD.20170405.1112.CEST