# 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:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![ptrk.mj](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ptrk.mj/32/300_2.png) [@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")

</div>

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

---

_[View the full topic](https://community.mp3tag.de/t/unexpected-regexp-behaviour-in-format-value-action/11919)._