Doesn't mod_lua do this for you?
> On Oct 1, 2015, at 8:51 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
>
> Am 01.10.2015 um 14:32 schrieb Nick Kew:
>> On Thu, 2015-10-01 at 12:26 +0200, Rainer Jung wrote:
>>> Since it gets more common to use the expression parser for string
>>> operations and not only for boolean checks, I think it would be useful
>>> (and powerful) to support
>>>
>>> s/PATTERN/REPLACEMENT/FLAGS
>>>
>>> and allow back references in REPLACEMENT. The operation would not try to
>>> do the replacement in place but create a new string according to the
>>> given PATTERN and REPLACEMENT.
>>
>> Are you mixing two things? That's well-established regexp syntax,
>> but you're looking at applying it to a different class expressions.
>> I think the most interesting issue is to define your behaviour.
>>
>>> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>>
>> Aha! In terms of the expression parser, that looks like
>> capturing a side-effect (as opposed to a true/false result).
>> Maybe it would work with something like C comma-list syntax?
>> But I expect the line of least resistance would be to use
>> plain regexp rather than expr.
>
> I'm talking about the use of the expression parser in the string context, not
> in boolean context. Support for string context started some time back and we
> now support it in more and more places. One could implement the
>
> var =~ s/PATTERN/REPLACEMENT/FLAGS
>
> syntax also as a four argument function regexreplace(var, PATTERN,
> REPLACEMENT, FLAGS), but the notation using s/.../.../ should be well-known
> to many so IMHO is preferable.
>
> So I want to enhance the expr syntax in string context to allow
>
> VARIABLE =~ s/PATTERN/REPLACEMENT/FLAGS
>
> This should return a string that is the result of the same operation in for
> example perl. VARIABLE will not be changed - unlike in perl - but the result
> string will be s/PATTERN/REPLACEMENT/FLAGS applied to VARIABLE.
>
> I think that is currently not possible with the expression parser but I
> expect it to be useful and if noone has a recipe how to get it done with our
> flex/bison definitions I'll try to find out.
>
> Since we don't support s/.../.../ right now, there shouldn't be to much
> compatibility hassle with existing expressions.
>
> Regards,
>
> Rainer
