Problem with setting substring match variables (%{1} etc.)
Alan DeKok
aland at deployingradius.com
Thu Aug 9 15:17:28 CEST 2007
Enrik Berkhan wrote:
> For testing, I've changed the inner 'no match or no subexpression match'
> condition of the four for-loops that are currently used to update
> %{0}... in the following way:
OK.
> This seems to work, variables are unset if they have an old value and no
> new value (no match at all or empty) or they are set/updated if they
> have a new value (match implied).
Hmm... on a regex match, all previous match information should be
deleted. This prevents old matches from polluting the variables for the
current match.
> I've only tested it using unlang:
>
>> if ("%{User-Name}" =~ /^(a)(.)(.)/) {
>> update reply {
>> Reply-Message := "first match: 0:%{0} 1:%{1} 2:%{2} 3:%{3} "
Isn't that just incredibly easy to use? :)
> The for-loops to update %{0}... are currently explicitly found in
>
> - src/main/evaluate.c
> - src/main/valuepair.c
> - src/modules/rlm_attr_rewrite/rlm_attr_rewrite.c (slight variation:
> doesn't touch the variables on no match)
> - src/modules/rlm_policy/evaluate.c
>
> Shouldn't this be moved to a single place like a function in
> src/main/util.c or main/xlat.c called xlat_update_regex or so?
Yes, probably.
> Further, I've noticed that in all places where regex-no-match operators
> are implemented but in src/modules/rlm_policy/evalute.c, the
> subexpressions are evaluated but never used later. May this could be
> fixed, too.
I seem to recall that in Perl, at least, !~ doesn't update $1, etc.
If that's useful, we can add that.
> Of course I could provide patches for all of this or parts thereof if
> it's the right direction. Just tell me what you'd prefer.
Just a patch for the existing code would be useful. Maybe after that,
factor out the regex code into one place.
Alan DeKok.
More information about the Freeradius-Devel
mailing list