Jim Breton <jamesb-lists(_at_)alongtheway(_dot_)com> writes:
I am getting an error on a pipe I call from a procmail rcfile; however,
the error only occurs when I use _more than one_ pipe. I'll show you
what I mean (I'm not actually intending to use 'cat' of course, but it's
the simplest way to demonstrate the problem):
...
./.procmailrc contains the following:
=====================================
DEFAULT=$HOME/test/
LOGFILE=$HOME/procmail.log
VERBOSE=yes
:0fw
| cat | cat
:0
$DEFAULT
=====================================
$HOME/test/ is a Maildir.
in procmail.log, the following is written:
procmail: [91103] Tue Aug 20 13:33:46 2002
procmail: Executing " cat | cat"
procmail: [91103] Tue Aug 20 13:33:46 2002
procmail: Program failure (1) of " cat | cat"
procmail: Rescue of unfiltered data succeeded
...
However, if I remove the second "| cat", I do not get this error.
To quote the procmailrc(5) manpage:
Recipe action line
The action line can start with the following characters:
...
| Starts the specified program, possibly in $SHELL if
any of the characters $SHELLMETAS are spotted.
...
SHELLMETAS If any of the characters in SHELLMETAS appears
in the line specifying a filter or program,
the line will be fed to $SHELL instead of
being executed directly.
That is, if the action being invoked doesn't contain any of the characters
in the SHELLMETAS variable ("&|<>~;?*[" by default), then procmail will
invoke it directly with using the shell. Since '|' is in SHELLMETAS,
adding the second command makes procmail invoke the action via the shell.
So it looks like there's something wrong with the SHELL value being used
by procmail. Try putting
SHELL = /bin/sh
at the top of the rcfile and see if that fixes the problem.
...
The other question I have is regarding the purpose of the '-m' option.
If I do not use it, procmail writes the following to stderr:
procmail: Couldn't create "/var/mail/jamesb"
In order to suppress that error, I have been calling procmail from my
~/.qmail* files like so:
The correct way to fix that problem is to recompile procmail with the
correct spool information. Why disable procmail's security checks
when you could have it check the correct location?
(And no, there is no way to change the spool location for the security
checks except to recompile procmail.)
Why does procmail even care about /var/mail/jamesb if I have re-defined
$DEFAULT?
Because that check is made before procmail even knows that you have a
.procmailrc file.
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail