On Thu, 27 Dec 2001, dman wrote:
> I was thinking that it would be really useful (and general) if the
> 'pipe' command (or perhaps "epipe" to maintain the current "pipe"
> semantics) would simply report the exit code of the sub process in a
> variable (such as $exitcode) that the filter script can check and
> decide what to do with it. For example :
Excuse me. I am very sorry about this, but I can't help it. I am going
to have to shout, because I've said this so many times before:
PIPE DELIVERIES ARE NOT RUN AT FILTER TIME.
The documentation tries very hard to say this, in several places. All
that happens during a user (or indeed system) filter is that delveries
are specified. They don't happen until later, along with all other
deliveries of the message.
Since the pipe is not run during the filter, its result cannot be
tested. Period.
If you want procmail-like functionality, use procmail, or write
something else that runs at delivery time.
> I think that this feature would allow exim filters to be infinitely
> extensible via external programs. Do you think this would be useful?
> Does the new ${run expansion already provide this functionality? If I
> made a patch (I haven't looked at the source yet, but I expect it
> would be quite simple) would you consider accepting it?
To answer the last question first: I can assure you, it won't be "quite
simple". It will be "completely re-design Exim to an entirely different
way of working".
The ${run facility does allow you to run a program at filter time. It
does not deliver the message to it, however.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
