------- 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
