>Народ! Помогите кто в состоянии. Максимум чего добился, это запись в лог
>данных при многоадресной рассылке, но хотелось бы добавлять эти данные в
>БД в реальном времени. Этого реально добиться? Заранее благодарен за ответ
>
Может быть вот это может как-то помочь? :
${run{<command> <args>}{<string1>}{<string2>}}
The command and its arguments are first expanded separately, and then the
command is run in a separate process, but under the same uid and gid. As in
other command executions from Exim, a shell is not used by default. If you
want a shell, you must explicitly code it. If the command succeeds (gives a
zero return code) <string1> is expanded and replaces the entire item;
during this expansion, the standard output from the command is in the
variable $value. If the command fails, <string2>, if present, is expanded.
If it is absent, the result is empty. Alternatively, <string2> can be the
word 'fail' (not in braces) to force expansion failure if the command does
not succeed. If both strings are omitted, the result is the standard output
on success, and nothing on failure.
The return code from the command is put in the variable $runrc, and this
remains set afterwards, so in a filter file you can do things like this:
if "${run{x y z}{}}$runrc" is 1 then ...
elif $runrc is 2 then ...
...
endif
If execution of the command fails (for example, the command does not |
exist), the return code is 127 - the same code that shells use for non- |
existent commands. |
Warning: In a router or transport, you cannot assume the order in which
option values are expanded, except for those pre-conditions whose order of
testing is documented. Therefore, you cannot reliably expect to set $runrc
by the expansion of one option, and use it in another.
The redirect router has an option called "forbid_filter_run" which locks
out the use of this expansion item in filter files.