dsearch: full-path return option
[exim.git] / doc / doc-docbook / spec.xfpt
index b9d73ad3f1d6ff6561eb11191e7df65f7bfc0a03..295835dbb0c00e3032632ab6898c9cb9cf66ee02 100644 (file)
@@ -6777,12 +6777,24 @@ absolute
 directory path; this is searched for an entry
 whose name is the key by calling the &[lstat()]& function.
 The key may not
-contain any forward slash characters. If &[lstat()]& succeeds, the result of
-the lookup is the name of the entry, which may be a file, directory,
-symbolic link, or any other kind of directory entry.
+contain any forward slash characters.
+If &[lstat()]& succeeds then so does the lookup.
 .new
+Options for the lookup can be given by appending them after the word "dsearch",
+separated by a comma.  Options, if present, are a comma-separated list with
+each element starting with a tag name and an equals.
+
+The only option currently supported requests an alternate output value of
+the entire path for the entry. Example:
+.code
+${lookup {passwd} dsearch,ret=full {/etc}}
+.endd
+The default result is just the requested entry.
+
+The matching entry may be a file, directory,
+symbolic link, or any other kind of directory entry.
 .cindex "tainted data" "dsearch result"
-It is regarded as untainted.
+The result is regarded as untainted.
 .wen
 An example of how this
 lookup can be used to support virtual domains is given in section
@@ -7029,7 +7041,11 @@ passed to a Redis database. See section &<<SECTsql>>&.
 .next
 .cindex "sqlite lookup type"
 .cindex "lookup" "sqlite"
-&(sqlite)&: The format of the query is a filename followed by an SQL statement
+&(sqlite)&: The format of the query is
+new
+an optional filename
+.wen
+followed by an SQL statement
 that is passed to an SQLite database. See section &<<SECTsqlite>>&.
 
 .next
@@ -7936,6 +7952,11 @@ If any MySQL, PostgreSQL, Oracle, InterBase or Redis lookups are used, the
 or &%redis_servers%&
 option (as appropriate) must be set to a colon-separated list of server
 information.
+.oindex &%mysql_servers%&
+.oindex &%pgsql_servers%&
+.oindex &%oracle_servers%&
+.oindex &%ibase_servers%&
+.oindex &%redis_servers%&
 (For MySQL and PostgreSQL, the global option need not be set if all
 queries contain their own server information &-- see section
 &<<SECTspeserque>>&.)
@@ -8073,17 +8094,31 @@ affected.
 .cindex "sqlite lookup type"
 SQLite is different to the other SQL lookups because a filename is required in
 addition to the SQL query. An SQLite database is a single file, and there is no
-daemon as in the other SQL databases. The interface to Exim requires the name
-of the file, as an absolute path, to be given at the start of the query. It is
-separated from the query by white space. This means that the path name cannot
-contain white space. Here is a lookup expansion example:
-.code
-${lookup sqlite {/some/thing/sqlitedb \
-  select name from aliases where id='userx';}}
+daemon as in the other SQL databases.
+
+.new
+.oindex &%sqlite_dbfile%&
+The preferred way of specifying the file is by using the 
+&%sqlite_dbfile%& option, set to
+.wen
+an absolute path.
+A deprecated method is available, prefixing the query with the filename
+separated by white space.
+This means that the path name cannot contain white space.
+.cindex "tainted data" "sqlite file"
+It also means that the query cannot use any tainted values, as that taints
+the entire query including the filename - resulting in a refusal to open
+the file.
+
+Here is a lookup expansion example:
+.code
+sqlite_dbfile = /some/thing/sqlitedb
+...
+${lookup sqlite {select name from aliases where id='userx';}}
 .endd
 In a list, the syntax is similar. For example:
 .code
-domainlist relay_to_domains = sqlite;/some/thing/sqlitedb \
+domainlist relay_to_domains = sqlite;\
    select * from relays where ip='$sender_host_address';
 .endd
 The only character affected by the &%quote_sqlite%& operator is a single