Problem with setting substring match variables (%{1} etc.)

Alan DeKok aland at
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:


> 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