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

Reply via email to