> Because you wrote ${expand:...} around the extraction.
ARG, of course.
Reading all those docs and man pages and those expansion strings over and
over again, I got completely blind for that...
> > BTW: So it seems the only 2 characters I need to escape in my files are " > > and \. I can simple prefix both with \. Right? (Assuming no #0, #10,
> > #13 are
> > used...)
> Also consider whitespace. There's a ${quote:...} expansion operator that
> may help.
Whitespaces shoud not matter as long as the string is double quotet, right?
Like this: pass="ab\$c d\!ef"
> Exim won't re-expand the string within one expansion, unless you explicitly > use ${expand:...}; it's a bit like why in shell you can have:
> foo='`bad-stuff`'
> bar="$foo"
> and "bar" ends up holding the same content as "foo". If you are passing the > data somewhere subject to expansion, then ${quote:...} helps.
So, as my arguments always come from an extraction, I do not use
${quote:...} as it would not be re-expanded anyway?
I fear I did not get the point.
> For shell: Exim doesn't use shell for constructing the pipe command-line, so > variables are passed safely in as individual items in argv; however, the
> "command" option _is_ subject to expansion, so you _will_ need to use
> ${quote:...} on the "command" line for the pipe driver, to protect against
> results containing '$'.
Isn't that a contradiction to "no re-expansion"?
> You may find "29.3 How the command is run" helpful.
I read that multiple times and again now. However it is unclear to me about
all those possible layers of quotation involved. The first expansion is
something I need to call the lookup/extract operator. Yet their output
should be passed through directly. If no re-expansion takes place, that
should fit. Do I need to take care of something like shell expansions? If no
shell is involved, I think I don't.
