Ugh. I tried s/SMART_DOMAINS_EXCEPT/SMART_EXCEPT_DOMAINS/g, and it
works. *Definitely* a bug. I didn't even consider the possibility that
a macro containing the the name of another macro might be a problem.
I very much like the idea of ${MACRO_NAME}.
--jim
%%%%%%%%%%%%%%% jim knoble %%%%%%%% jmknoble@??? %%%%%%%%%%%%%%%%%
On 13 Jul 1998, Harald Meland wrote:
: My guess: I think it is a bug that just because you happened to define
: a macro with a name consisting of a previously defined macro and some
: suffix, it's always the first macro that gets expanded. I.e.,
:
: "SMART_DOMAINS_EXCEPT" => "*_EXCEPT"
:
: which obviously isn't what you wanted. One might argue that this is
: the behaviour to be expected, as the spec says:
:
: Once a macro is defined, all subsequent lines in the file are scanned
: for the macro name; if there are several macros, the line is scanned
: for each in turn, in the order in which they are defined.
:
: Bandaid fix: Either define SMART_DOMAINS_EXCEPT above SMART_DOMAINS,
: or do something like s/SMART_DOMAINS_EXCEPT/SMART_EXCEPT_DOMAINS/g .
:
: This could be fixed by introducing some explicit "expand this macro
: here" syntax. Maybe preserving capitalized variable names for
: "quasi-macros" and define global variables instead of macros,
: dereferencing them by ${MACRO_NAME}, would be a better solution? Such
: a "fix" would break old config files, though...
:
: --
: Harald
--
*** Exim information can be found at
http://www.exim.org/ ***
