On Thu, 6 Sep 2001, Sheldon Hearn wrote:
> Can't regular expressions be identified in a way that's similar to
> scheme used for lookups? I.e.
>
> hold_domains = pcre;^\d+.*\.com$
>
> Would that help?
No. The point is that the expansion is happening *before* interpretation
of the string as a list. This is so that you do cunning things. For
example, in the new ACL for policy checking, you can do things like
this:
deny senders = ${lookup{$local_part}dbm{/some/file}}
which gets a list of blocked senders for the current local part.[1] The
contents of such a list could include a regular expression, no problem.
The difficulty is if you want to write
deny senders = ^.*@.*\.bad\.domain$
because Exim will first expand that before interpreting it, and I've got
myself into a mess by using $ and \ as special characters in expansions.
There's a fudge for $ that I think I could wear: if $ in an expansion is
not followed by { or a letter or a digit, treat it as a literal $. That
would probably let through all dollars in regular expressions. However,
if I were to do that, the above example would expand successfully, but
the result would not be the regex you expect, so I'm not sure the fudge
is wise.
Another tempting fudge is to make ^ special in expansions, but
unfortunately there is no obvious way of finding the end of a regular
expression.
At the moment, my favoured solution is to implement some kind of "don't
expand" magic.
---------------
[1] Note that this is completely different to
deny senders = dbm;/some/file
which looks up the current sender in the file, and denies if it is
found. (For added complication, the former could expand to the latter.)
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
