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

**URL:** https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858
**Category:** No Bugs
**Created:** [April 4, 2017, 4:12am UTC](https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858 "2017-04-04T04:12:30Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![soupcan113](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/49beb7/32.png) [@soupcan113](https://community.mp3tag.de/u/soupcan113)
#### Post date: [April 4, 2017, 4:12am UTC](https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858/1 "2017-04-04T04:12:30Z")

</div>

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".

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 4, 2017, 4:19am UTC](https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858/2 "2017-04-04T04:19:26Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [April 4, 2017, 6:31am UTC](https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858/3 "2017-04-04T06:31:24Z")

</div>

> [@soupcan113](#):
>
> This is a very specific issue ... It could be bug that occurs across the entire program when dealing with using _Regex_ ...

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](https://community.mp3tag.de/t/11096/28)

DD.20170404.1031.CEST

---

<div class="post-metadata">

### Author: ![soupcan113](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/49beb7/32.png) [@soupcan113](https://community.mp3tag.de/u/soupcan113)
#### Post date: [April 5, 2017, 4:31am UTC](https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858/4 "2017-04-05T04:31:47Z")

</div>

> [@DetlevD](#):
>
> Your problem is self inflicted, because you did not respect the rules for the Mp3tag scripting language.

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](https://coderanch.com/mobile/t/416642/java/parenthesis-string)

> [@DetlevD](#):
>
> Round brackets have to be devalued, when using them as literal characters.

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.

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [April 5, 2017, 7:10am UTC](https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858/5 "2017-04-05T07:10:52Z")

</div>

> [@soupcan113](#):
>
> ... My examples use a backslash to devalue the round brackets, which according to the Help page is valid. ...

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 ...  
[https://docs.mp3tag.de/scripting](https://docs.mp3tag.de/scripting)

DD.20170405.1112.CEST

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 6:51pm UTC](https://community.mp3tag.de/t/x-suspected-bug-regarding-matching-unclosed-string-parenthesis-in-regex/18858/6 "2018-12-28T18:51:17Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
