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 <[email protected]> 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
