# Unexpected regexp behaviour in "Format value" action
**URL:** https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919
**Category:** Support
**Created:** [April 26, 2011, 11:39am UTC](https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919 "2011-04-26T11:39:50Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@anon40688970](https://community.mp3tag.de/u/anon40688970)
#### Post date: [April 26, 2011, 11:39am UTC](https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919/1 "2011-04-26T11:39:50Z")
I have got a file named `test.mp3`. My action group consist of a single "Format Value" action:
Field: `_FILENAME`
Format String: `$regexp(%_filename%,(.*),$1 oops).mp3`
After executing the action !once!, my file is renamed to
`test oops oops.mp3`
Bug? Feature? What's happening here?
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [April 26, 2011, 1:53pm UTC](https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919/2 "2011-04-26T13:53:03Z")
> [@anon40688970](#):
>
> ... Bug? Feature? What's happening here? ...
Even more fun ...
`_filename <== 'test'`
`$regexp(%_filename%,'.',' oops') ==> ' oops oops oops oops'`
... this seems to be ok.
`$regexp(%_filename%,'()',' - - - ') ==> ' - - - t - - - e - - - s - - - t - - - '`
... but here I have a problem to understand.
DD.20110426.1805.CEST
---
### Author:  [@anon40688970](https://community.mp3tag.de/u/anon40688970)
#### Post date: [April 26, 2011, 1:59pm UTC](https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919/3 "2011-04-26T13:59:59Z")
> [@DetlevD](#):
>
> Even more fun ...
> `$regexp(%_filename%,'.',' oops')`
>
> DD.20110426.1754.CEST
A workaround seems to be
Field: `_FILENAME`
Format String: `$regexp(%_filename%,(.+),$1 oops).mp3`
the `+` enforces that the part inside the subexpression has at least one character, thereby supressing the second, zero-width match.
---
### Author:  [@ptrk.mj](https://community.mp3tag.de/u/ptrk.mj)
#### Post date: [April 30, 2011, 5:44pm UTC](https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919/4 "2011-04-30T17:44:17Z")
This is not a bug. This is one of the quirks of regex engines. I've mentioned it before in [another bug report](https://community.mp3tag.de/t/10558/1).
> [@Strange regex engine behavior with a lazy star token](https://community.mp3tag.de/t/strange-regex-engine-behavior-with-a-lazy-star-token/10558/3):
>
> As I explained in the first post regex engines apart from matching at each character offset (...) also try to match a pattern at an offset behind the last character (i.e. match a pattern against void at the end of the string) (...)
`$regexp(test,(.*),$1 oops)`
1. `.*` matches the whole string (start of the match at offset 0).
2. Match ("test") is captured into first backreference.
3. Match is replaced with `$1 oops` so that "test" becomes "test oops".
4. `.*` matches void after the string (start of match at offset 1, zero-width match). Star makes the dot _optional_ so that the pattern can match here!
5. Match ("") is captured into first backreference. That's right! The first backreference _exists_ and simply holds _nothingness_.
6. Match is replaced with '$1 oops' so that "" becomes " oops"
After all, our input string "test" becomes "test oops oops".
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:23pm UTC](https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919/5 "2026-02-09T12:23:03Z")