On 19/03/2023 17:22, Ian Z via Exim-users wrote:
> Chapter 24 documents the transport_filter option. An example is given
> where the argv vector for the command comes from an expansion:
>
> transport_filter = '/bin/cmd${if eq{$host}{a.b.c}{1}{2}}'
>
> This runs the command /bin/cmd1 if the host name is a.b.c, and
> /bin/cmd2 otherwise. If double quotes had been used, they would have
> been stripped by Exim when it read the option’s value. When the
> value is used, if the single quotes were missing, the line would be
> split into two items, /bin/cmd${if and eq{$host}{a.b.c}{1}{2}, and
> an error would occur when Exim tried to expand the first one.
>
> I have two problems grokking this:
>
> - I can find no other place in the spec where it is specifically
> explained what single quotes do, as opposed to double quotes.
Yup; this could be better.
In the coding I find an explanatory comment:
/* Split the command up into arguments terminated by white space. Lose
trailing space at the start and end. Double-quoted arguments can contain \\ and
\" escapes and so can be handled by the standard function; single-quoted
arguments are verbatim. Copy each argument into a new string. */
>
> - In Section 29.3 on pipe commands (which are supposedly expanded the
> same way), there is this example:
>
> command = /some/path ${if eq{$local_part}{postmaster}{xx}{yy}}
>
> will not work, because the expansion item gets split between
> several arguments. You have to write
>
> command = /some/path "${if eq{$local_part}{postmaster}{xx}{yy}}"
>
> So why are double quotes OK here?
The difference is an artefact of the option-handling described in
Ch.6 Sec.17 :- if an option value *starts* with a doublequote
then it must end with one (and, implicitly, they get stripped
at that processing phase. The pipe example does not.
--
Cheers,
Jeremy
