On Thu, 24 Jan 2002, David W. Tamkin wrote:
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.
David,
Many thanks for your response. I'm not sure that you mean that
*only* the folder's name will get into the logfile, and not the rest of
the (truncated) line.
When I substitute the name of my procmail folder
| >> .procmail formail-command with lots of parameters
I still get the log and mailstat reading the action command literally. The
whole truncated line is still the folder name.
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.
I used parentheses as you have them (but no semicolons) and still get the
literal truncated line as the folder name. Any idea what I'm doing wrong?
In the verbose log there's a complaint when I add a "/" before the folder
name or even a path:
/bin/sh: /.procmail: cannot create
It would appear that I'm asking more than procmail is prepared to
give me. If that's so, in the log and in mailstat "Folder:" might be
renamed "Destination:".
KENNETH BLACKWELL
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail