httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
Date Thu, 01 Oct 2015 13:25:38 GMT
Am 01.10.2015 um 15:03 schrieb Jim Jagielski:
> Doesn't mod_lua do this for you?

But would it be the right tool to use whenever you want to apply a 
s/.../.../? I think the entry bar for mod_lua is higher than to get used 
with s/.../.../ syntax in the expression parser - though the docs for 
expr could be better (have that on my list), especially concerning the 
different syntaxes in boolean and string mode.

>> On Oct 1, 2015, at 8:51 AM, Rainer Jung <rainer.jung@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


Mime
View raw message