Re: [exim-dev] [Bug 474] ACL condition to unset a variable

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Jakob Hirsch
Data:  
Para: 474
CC: exim-dev, to.roma.from.eximbug
Assunto: Re: [exim-dev] [Bug 474] ACL condition to unset a variable
Hi,

first, please let us discuss this on exim-dev, bugzilla is not a
discussion forum.


> Both proposed changes are quite important, especially isset.
>
> In many cases one needs to distinguish between variables containing the empty
> string and nonexistent variables. Of the predefined variables, $spam_bar comes
> to mind: it can be empty for ham messages, or it can be undefined before spam
> testing takes place. Or some conditions can be cached, as in:


You can easily look at $spam_score* to see if $spam_bar contains
something valid.

>   warn
>     condition = ${if !isset:acl_m_some_acl_result}
>     set acl_m_some_acl_result = ${if some-heavy-condition}


condition = ${if !def:acl_m_some_acl_result}
set acl_m_some_acl_result = ${if some-heavy-condition {yes}{no}}

I see that it's more to type. And that it was a questionable decision to
expand false ${if..} to the empty string, when the short format of it
was introduced.

> The problem is aggravated by strict_acl_vars, with which one can’t check for
> unset variables at all.


strict_acl_vars was intended for detecting typos. If you want to use it,
I would suggest to set all variables you want to use as early as
possible to the empty string (which is essentially like using the "my"
function in perl, which you need when using "use strict", therefore the
name strict_acl_vars).
btw, strict_acl_vars would inhibit the use of your "isset:" operator,
because testing for an unset variable would result in an expansion error.

> unset would also be useful, though to a less extent. The idea is not to spare
> resources, but to add more expressive possibilities. For example, the caching


As shown, this is already possible.

> re-evaluation. The problems with removing tree nodes are solvable, I guess the
> tree is basically what C++ would call std::map<std::string, std::string>? The
> C++’s map can remove elements easily, your tree should allow that as well.


Of course it's solvable. But exim is not written in C++, and we would
need to add complex code for no real benefit.