X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/0f06b4f296802e4e13188c740ea09419931a3020..ac4ef9bdcad6bb41c919f6d0b76fdef717ab5e18:/doc/doc-docbook/spec.xfpt?ds=sidebyside

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index ffe153ae9..df63ad6a0 100644
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -6875,12 +6875,6 @@ ${lookup dnsdb{ptr=192.168.4.5}{$value}fail}
 If the data for a PTR record is not a syntactically valid IP address, it is not
 altered and nothing is added.
 
-.cindex "MX record" "in &(dnsdb)& lookup"
-.cindex "SRV record" "in &(dnsdb)& lookup"
-For an MX lookup, both the preference value and the host name are returned for
-each record, separated by a space. For an SRV lookup, the priority, weight,
-port, and host name are returned for each record, separated by spaces.
-
 For any record type, if multiple records are found (or, for A6 lookups, if a
 single record leads to multiple addresses), the data is returned as a
 concatenation, with newline as the default separator. The order, of course,
@@ -6893,6 +6887,16 @@ ${lookup dnsdb{>: a=host1.example}}
 It is permitted to specify a space as the separator character. Further
 white space is ignored.
 
+.cindex "MX record" "in &(dnsdb)& lookup"
+.cindex "SRV record" "in &(dnsdb)& lookup"
+For an MX lookup, both the preference value and the host name are returned for
+each record, separated by a space. For an SRV lookup, the priority, weight,
+port, and host name are returned for each record, separated by spaces.
+.new
+An alternate field separator can be specified using a comma after the main
+separator character, followed immediately by the field separator.
+.wen
+
 .cindex "TXT record" "in &(dnsdb)& lookup"
 .cindex "SPF record" "in &(dnsdb)& lookup"
 For TXT records with multiple items of data, only the first item is returned,
@@ -9694,6 +9698,37 @@ the regular expression from string expansion.
 
 
 
+.new
+.vitem &*${sort{*&<&'string'&>&*}{*&<&'comparator'&>&*}{*&<&'extractor'&>&*}}*&
+.cindex sorting a list
+.cindex list sorting
+After expansion, <&'string'&> is interpreted as a list, colon-separated by
+default, but the separator can be changed in the usual way.
+The <&'comparator'&> argument is interpreted as the operator
+of a two-argument expansion condition.
+The numeric operators plus ge, gt, le, lt (and ~i variants) are supported.
+The comparison should return true when applied to two values
+if the first value should sort before the second value.
+The <&'extractor'&> expansion is applied repeatedly to elements of the list,
+the element being placed in &$item$&,
+to give values for comparison.
+
+The item result is a sorted list,
+with the original list separator,
+of the list elements (in full) of the original.
+
+Examples:
+.code
+${sort{3:2:1:4}{<}{$item}}
+.endd
+sorts a list of numbers, and
+.code
+${sort {$lookup dnsdb{>:,,mx=example.com}} {<} {${listextract{1}{<,$item}}}}
+.endd
+will sort an MX lookup into priority order.
+.wen
+
+
 .vitem &*${substr{*&<&'string1'&>&*}{*&<&'string2'&>&*}{*&<&'string3'&>&*}}*&
 .cindex "&%substr%& expansion item"
 .cindex "substring extraction"
@@ -16828,15 +16863,18 @@ of the other precondition options are common special cases that could in fact
 be specified using &%condition%&.
 
 .new
-When originally designed, Exim's ACL system enforced very strict parsing
-of the &%condition%& expansion everywhere it was being processed.
-Through the 4.7x release cycle, the &%condition%& processing while in a
-router became more loose, internally adopting the use of &%bool_lax%&
-instead of the more rigid &%bool%&.  This is best illustrated in an
-example:
+Historical note: We have &%condition%& on ACLs and on Routers.  Routers
+are far older, and use one set of semantics.  ACLs are newer and when
+they were created, the ACL &%condition%& process was given far stricter
+parse semantics.  The &%bool{}&% expansion condition uses the same rules as
+ACLs.  The &%bool_lax{}%& expansion condition uses the same rules as
+Routers.  More pointedly, the &%bool_lax{}%& was written to match the existing
+Router rules processing behavior.
+
+This is best illustrated in an example:
 .code
-# This used to fail with a syntax error, now it
-# treats any extra characters as a string
+# If used in an ACL condition will fail with a syntax error, but
+# in a router condition any extra characters are treated as a string
 
 $ exim -be '${if eq {${lc:GOOGLE.com}} {google.com}} {yes} {no}}'
 true {yes} {no}}
@@ -16854,10 +16892,16 @@ resulted in the null output (indicating false) with the string
 &" {yes} {no}}"& appended to it.
 
 In fact you can put excess forward braces in too.  In the router
-&%condition%&, Exim's ACL parser only looks for &"{"& symbols when they
+&%condition%&, Exim's parser only looks for &"{"& symbols when they
 mean something, like after a &"$"& or when required as part of a
 conditional.  But otherwise &"{"& and &"}"& are treated as ordinary
 string characters.
+
+Thus, in a Router, the above expansion strings will both always evaluate
+true, as the result of expansion is a non-empty string which doesn't
+match an explicit false value.  This can be tricky to debug.  By
+contrast, in an ACL either of those strings will always result in an
+expansion error because the result doesn't look sufficiently boolean.
 .wen