Kenneth Blackwell asked,
| Although the first line of data in my mailstat report is not a
| real folder, it is a pipe destination and is logged in place of a folder
| name. Isn't this what I should expect?
Yes, it is.
The "Folder" column of mailstat's output tallies the Folder: entries from
your procmail log. When delivery is to a pipe, that will be the command from
the pipe (without the leading pipe symbol). When the command string is very
long, procmail will truncate it, and mailstat will see only what's left. So
if the command finishes by appending to a folder, like this:
:0 flags:
* conditions
| a command here with lots of options and parameters or whatever >> folder
# or
#| (command 1; command 2: command3|command4; echo "I want my Mommy") >> folder
not all of that text from the action line will get into the logfile, and if
your eyes don't see it in the logfile, mailstat won't either.
If you have a lot of recipes where the same command appends to a variety of
folders and the name of the folder is more important for your log data than
all the arguments to the command, you can do this:
| >> folder command with lots of parameters
That way the folder's name will get into the logfile.
For the second situation, I think most shells (since procmail needs a shell
to handle the appending, it's a given that procmail will invoke a shell for
such a command) should allow this:
| >> folder (command1; command2)
Procmail will infer a name for the local lockfile by appending $LOCKEXT to
the first word after ">>", so you're still safe using implicit local lockfile
names.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail