Matthias Andree <ma+cou...@dt.e-technik.uni-dortmund.de> writes:
Courier User <cour...@asfast.net> writes:
Even though maildrop appears to treat these two cases identically,
child processes invoked via xfilter and other means could have
problems with this. This happens because environment variables are
inherited by child processes, which in the general case cannot be
counted on to look at these two instances as being equivalent ...
and in quite a few common cases, they do not.
...
Thoughts?
Check out the env(1) command.
Untested:
xfilter 'env VARIABLE= /usr/local/bin/your-command'
Yes, this works. And in fact, I'm already doing this as a workaround to
the current maildrop behavior.
However, I still think that it is misleading that the following
statement causes the environment variable to be deleted intead of
being bound to an empty string:
VARIABLE=""
Also, it becomes quite unwieldy to use this 'env' method when there are
a number of variables that are set to "" ... each one has to be
mentioned multiple times: once in the maildroprc or .mailfilter file if
the variable is referenced there; and the second through n-th times
after 'env' on the command line of every xfilter command which might use
the variables.
It seems to me that it would be a lot clearer, and less in violation of
"The Principle of Least Surprise", if maildrop's behavior is changed
the way I described in my previous email.
4 messages in net.sourceforge.lists.courier-maildrop[maildropl] Re: Setting environment v...
.patch
