Well I know the PATH=`which procmail` works. It's being used on another
machine that uses procmail and there aren't any problems. Basically it
runs which procmail when it asks for where procmail is located. (I was
doing a lot of shell scripting at the time, that's why I used that.)
[timh(_at_)yoda timh]$ echo "`which procmail`"
So when it looks for procmail it will get that.
We all know that `which procmail` will work... the question is: Why set it
to be the same as a crucial system variable, when there are infinite+1 other
BTW it is a total waste of processing power to set that, IMO.
If 'procmail' isn't in $PATH, then 'which procmail' will give you an invalid
response, but since you never test for an invalid response, it really
doesn't make any sense to use it. It calls an external program every single
time a mail message gets delivered, which is entirely unnecessary, and it
mucks up an important variable.
What benefit do you think you are getting by setting $PATH=`which procmail`
? There's no reason why you can't just use 'procmail' instead of '$PATH'.
If you have to set a variable, use "$PROCMAIL=`which procmail`" or some
such.... it's still a waste of processing power, but at least it won't mess
up the system variable.
I know that's not the problem, like I said I have it running like that at
6 different locations and it works fine.
There's nothing more "portable" about using a .procmailrc with that set.
Again, 'procmail' has to be in the $PATH when you use 'which procmail'
already anyway, so why bother?
procmail mailing list