------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1324
--- Comment #4 from Phil Pennock <pdp@???> 2012-12-20 22:30:31 ---
Exim treats "foo =" for a string option as "option is unset"; there's no
difference between "set to empty" and "not set at all", we don't have pointers
or container data structures (and if we did, we wouldn't make the sysadmin
initialise the memory for the list/map before they could use it). The closest
we come is that a container can contain an empty element, so the container
(pseudo-list) can be of length 1, but that item is itself of length 0.
In most cases, the compile-time option controls the default for the string and
so unset just stops using that compile-time default.
Logs are so central that we don't provide such a simple way to accidentally
lose them. There's a fallback. If you don't explicitly shut down all logging,
we log to a failsafe.
What is unusual here is that instead of exposing the compile-time default as a
variable and letting the user filter it to deselect a particular item, we have
a historical behaviour switch. There was a slight error in my previous
bugzilla comment. Sorry. So: assigning a list with an empty item takes the
compile time default and filters out any elements which match "syslog".
Thus:
log_file_path = :
is equivalent to this pseudo-code
log_file_path = ${filter {COMPILE_TIME_LFP}{${if !eq{$item}{syslog}}}}
But that was added before ${filter} came into the Exim configuration language,
and we don't export the compile-time default.
This seems like the sort of weird feature that someone would be using and I
don't see the value in removing it.
Documentation patches welcome.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
