Matching a prefix in huntgroups file

[Brian Candler]

On 09/11/2016 19:44, Alan DeKok wrote:
>    So... &Foo is *always* an attribute reference.  /foo/ is *always* a regex.  "foo" is *always* an expanded string.  'foo' is *always* a constant string.  And bare words are... of the devil.
It seems to me that bare numbers, and bare ipv4/ipv6 addresses and 
prefixes, could be recognised as such by the lexical analyser pretty 
easily.  If you want the string "345" or "1.2.3.4" instead, then you put 
quotes around it.

I think that covers most of the radius data types. I suppose you could 
parse MAC addresses too, but that would be rarely used.

>
>    If both sides are bare words, who knows what the heck they ware.  So they're treated as strings.
Perhaps it would be better to bomb out in that case. It's hard to think 
of any case where both sides as string literals is actually *useful*, 
and if for some reason you really wanted that, you could just use quotes.

So the only bareword string-like thing that's really needed is a 
dictionary enumerated value; and as those are restricted to being on the 
RHS where the LHS is a dictionary attribute, then that's not really a 
problem.

&Service-Type == Login-User   # fine
Login-User == &Service-Type   # no good reason I can see for this
Service-Type == 1             # pretty pointless

If you wanted, there could be something like Service-Type::Login-User as 
an explicit way to select an enumeration value.  That is: any bare-word 
which doesn't look like a number or IP address is an enumeration, and 
the attribute qualifier is optional if the LHS is an attribute.

Bikeshed: I did think that "$" or "@" would look more natural as a way 
to access the value of an attribute :-)

Regards,

Brian.