On 06 Oct 2015, at 12:17 AM, Stefan Fritsch wrote:
>> How about a regex function?
>>
>> The single argument could be “s/PATTERN/REPLACEMENT/FLAGS”.
>
> I think this would be easy to implement. It would require the regex to
> be parsed on every execution, though, which has the disadvantages tha
On Sunday 04 October 2015 12:51:13, Graham Leggett wrote:
> On 04 Oct 2015, at 12:46 PM, Rainer Jung
wrote:
> > Yes, I agree. When starting to think closer, I noticed that the
> > string mode currently only supports a syntax that is pretty
> > different from the boolean mode and is much more limi
On 04 Oct 2015, at 12:51 PM, Graham Leggett wrote:
> How about a regex function?
>
> The single argument could be “s/PATTERN/REPLACEMENT/FLAGS”.
Or more specifically:
%{regex:%{REMOTE_USER} =~ /([^@]*)@.*/$1/}
Or perhaps to avoid the issue of having to escape the =~ characters this:
%{regex:
On 04 Oct 2015, at 12:46 PM, Rainer Jung wrote:
>> But it must not be too complicated. We don't want an unreadable mess
>> like the sh/bash string manipulation functions.
+1.
> Yes, I agree. When starting to think closer, I noticed that the string mode
> currently only supports a syntax that i
Am 04.10.2015 um 10:23 schrieb Stefan Fritsch:
On Thursday 01 October 2015 13:55:40, Rainer Jung wrote:
Am 01.10.2015 um 12:31 schrieb Graham Leggett:
On 01 Oct 2015, at 12:26 PM, Rainer Jung
wrote:
Since it gets more common to use the expression parser for string
operations and not only for
On Thursday 01 October 2015 13:55:40, Rainer Jung wrote:
> Am 01.10.2015 um 12:31 schrieb Graham Leggett:
> > On 01 Oct 2015, at 12:26 PM, 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
On Thu, Oct 1, 2015 at 2:44 PM, Rainer Jung wrote:
>
> OK, at least an encouragement for me to have a closer look.
+1!
On 01 Oct 2015, at 4:31 PM, Nick Kew wrote:
>> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>
> One further thought there that might be easier to work,
> or a staging post on the way to your goal:
>
>
>X-USER = $_
> # (or whatever backref syntax you prefer).
>
The reas
On Thu, 1 Oct 2015 15:25:38 +0200
Rainer Jung wrote:
> 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/.../.../?
Some might say so (as some might say mod_perl or mod_rewrite).
>
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
exp
Doesn't mod_lua do this for you?
> On Oct 1, 2015, at 8:51 AM, Rainer Jung 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 ch
On Thu, 2015-10-01 at 13:32 +0100, Nick Kew wrote:
> > Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
> But I expect the line of least resistance would be to use
> plain regexp rather than expr.
Come to think of it, using regexp that looks a lot like:
${REMOTE_USER} =~ s/([^@]*)
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 allo
Am 01.10.2015 um 14:33 schrieb Eric Covener:
On Thu, Oct 1, 2015 at 6:26 AM, 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 al
> -Ursprüngliche Nachricht-
> Von: Rainer Jung
> Gesendet: Donnerstag, 1. Oktober 2015 13:56
> An: dev@httpd.apache.org
> Betreff: Re: Expression Parser: search and replace with
> s/PATTERN/REPLACEMENT/FLAGS
>
>
> The example might be artificial and mod_head
On Thu, Oct 1, 2015 at 6:26 AM, 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.
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 REPLACE
On Thu, Oct 01, 2015 at 01:55:40PM +0200, Rainer Jung wrote:
> Something different. Example:
>
> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>
> ...
>
> The example might be artificial and mod_header might support doing
> this in another way, but IMHO it would be a nice general f
Am 01.10.2015 um 12:31 schrieb Graham Leggett:
On 01 Oct 2015, at 12:26 PM, 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
On 01 Oct 2015, at 12:26 PM, 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
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 b
21 matches
Mail list logo
