Alexander V Alekseev wrote:
This is my last reply to you, because this discussion is pointless.
>>Because it will BREAK configurations, why do YOU not just use escaping,
>>like anyone else would do in such a situation? I do escape } and { if i
>
> BTW, if you always escape your {} , you needn't worry about.
>
>>need them in between and i did it because it was logical.
>
> Really, I don't know exim's language good enough to give you
> example just from docs, but the trouble occur, if you have construct
I know it very well, and i think some people here could tell you i know
how to use it.
> like this: operation1{operation2{something}} and need first to
> expand operation1 using "operation2{something}" as argument, and only
> after that you need to expand "operation2{something}" into new string.
This isn't how exim works, all arguments will be expanded before used,
example
${if eq {$local_part}{${lc:$local_part}} {yes} {no}}
This will work, the rgument wills be expanded before used, but to come
back to your example:
This would be the correct way for exim, for what you want:
${expand:${operation1{\N${operation2{something}}\N}}}
> I think, you can invent current example yourself.
> But I can explain, why I need this feature: I tried to speedup
> lookup process to any lookup type you want. How can we do it? The only
> way of doing it (without modifying all lookup types) is to wrap
> cashed lookups in a new lookup types. For example, if you have (just
> from spec.txt):
> ################################################
> data = ${lookup mysql{ALIAS_QUERY}}
> ################################################
> so I rewrite it as follows:
> ################################################
> data = ${lookup sharedcashe {lookup mysql{ALIAS_QUERY}} }
> ################################################
> and we first look in cashe, using string "lookup mysql{ALIAS_QUERY}}" as
> key, and if nothing found, add '${' before and '}' after the lookup
> key, and expand the string once more.
> If you always escape your {} , nothing bad will happen. But it's
> too ugly to change {} to anything alse in case shown.
Wrap it in \N TEXT \N, this is what this was made for.
>> > There are no words about "escape a char if it could cause trouble"!
>>
>>Yes, sometimes one should THINK! ;)
>
> But there is no idea in documentation, that unescaped {} should
> sometimes work! They should never work, or be clearly documented!
Why not?
Write it 100 times
This is not C
This is not C
.....
>>In fact, i'm reading this list since some years, and i NEVER saw someone
>>complaining about it, i think until now anyone was clueful enough to
>>just escape the }.
>
> You're right. Everyone escapes them. So, what do you worry about?
Your patch WILL break stuff, you are thinking in terms of a complete
script parser, but exim's expansion language is made for speed (Philip
will decline this (as usual), but it's true ;) ), the parser just cares
about things he NEED to know at this moment, not more, not less.
>>The exim-parser is meant to be FAST, not to be a complete scripting
>>solution, i think Philip would have used Yacc or Bison if he wanted
>>something like this.
>
> I just add 1 integer compare per '}' found. And 1 integer "++"/"--"
> operation per '{' or '}' found. Do you think it'll slow down parce
> process? (May be you have millions of '{' or '}' in your config, but I
> can't imagine it.)
You got me wrong, Exim acts like as it should, it just interferes with
the chars it needs at THIS moment, this is the concept, your patch
destroys this.
> BTW, I did that just to speedup overal speed. (Though
> exim's speed is quite discussible. On my P4 1.8 / 256M I see only
> about 100 messages per second enqueued, and about 30 messaged per second
> relayed. On such configuration, CGP enqueues more 1000 messages per second,
> and relays about 300. ;-(( I used default config, supplied with exim,
> but changed all lookup to MYSQL. Using default lsearch fails to
So maybe you should think about changing to something else
(cdb,dbm,tdb,ldap,whatever). Maybe you should read spec.txt for the
usual performance-hints, and learn about address_data etc.
exim -d helkps to find bottlenecks too, be creative, not destructive.
> extremely low speed. The main trouble is fork(), and reinitialisation.
> But I don't think, it's really possibly to make exim threaded in a
> moderate period of time. )
I would not want exim to be threaded, exim avoids to synchronize as much
as possible, and that's good.
>>Hu?
>>Why should i need to predict them?
>>I just escape } and { if they are located in a string.
>>And you don't need balanced constructs all the time, don't you
>>understand this? a } could be without any { in a string, what you do, is
>>BREAKING this, you break something that isn't wrong at all.
>
> You pointed out, that everyone escapes {}. That's right. Why do
> you think then, such undocumented bug should be supported? For someone,
> who don't read the documentation?
Why it should be a bug?
If exim would use perl-,ruby-,python- or *-like expressions for the
configuration i would say "ok, it MUST be like in the real language",
but this is exim.
