On Tue, Sep 20, 2005 at 04:55:41PM +0100, Philip Hazel wrote:
> It would need to be something entirely different. Consider
>
> condition = ${lookup ....}
>
> There's no "if" involved there. "if" is only one feature of string
> expansions. If you want to change to
>
> condition = eq{string1}{string2}
>
> then the whole rhs has changed its semantics rather drastically. It's
> no longer a generalized expanded string, but some specific conditions.
> For compatibility, one would need to have a different name, e.g.
>
> iftrue = eq{string1}{string2}
That's why I mentioned first sets. All expansion conditions (which are
basically boolean expressions, compared to string expressions) start
with the name of a function that evaluates to a boolean result. String
expressions, on the other side, start with probably everything else.
Unfortunately, I just see you are right:
condition = eq{string1}{string2}
evaluates to true in Exim 4, because it is not the empty string, "0", "no"
or "false". Although I am sure this has bitten many users who would
have loved to get an error message, changing that by now probably bites
someone real bad and not even I dare to suggest that change. See, I said
I was bad at guessing first sets, but at least that's the answer why
condition does not take boolean expressions besides string expressions. ;-)
How about adding the above example to the manual?
I suggest to name the new option "if":
if = eq{string1}{string2}
Unless we start introducing operators, which I really would like not
to, we shouldn't need any line continuation backslashes inside boolean
expressions.
Optionally, let "condition" log a warning if it evaluates to a string
that starts with a boolean function, like "eq{".
Michael
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
