Suppose that you have a ${run ...} in a router such as the following:
address_data = ${run{/opt/mail/sbin/matchposters.py $return_path /cs/lists/$local_part..posters} {<some IP address>} fail}
Now suppose that this is invoked with the null sender, <>.
What I expected to happen is that matchposters.py would be invoked
with two command line arguments; the first would be empty (because
$return_path is empty due to the null sender) and the second part
would be the appropriate expansion.
However this is not what happens in Exim 4.76 (Ubuntu 12.04) and Exim
4.82 (Ubuntu 14.04). Instead matchposters.py is invoked with only *one*
command line argument as the empty $return_path is scrubbed out of the
argument list entirely. As far as I can tell there is no way to stop
this from happening.
I don't believe that this is desirable. I feel strongly that command
line expansions should not vary a command's argument count based on
whether or not some expansions happen to be empty. At a minimum doing
so makes commands run from ${run...} more fragile and more complex;
if empty expansions are ever a possibility, they must attempt to deduce
what arguments were empty from how many arguments they have.
(Alternately one carefully surrounds expansions with marker characters
and then strips the marker characters from appropriate arguments in the
command, which can best be described as 'a massive hack workaround'.)
At a minimum I feel that this should be explicitly documented in
the ${run} section of the String Expansions chapter of the Exim
documentation.
- cks
