Re: [exim] Does EXIM need a new scripting language? - YES

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