Bart Schaefer <schaefer(_at_)zanshin(_dot_)com> writes:
[...]
It cause several things to be double printed like this:
procmail: Assigning "EXITCODE=0"
procmail: Executing "formail,-XMessage-Id:"
procmail: Executing "formail,-XMessage-Id:"
Message-Id:
<200110290051(_dot_)f9T0p5915862(_at_)reader(_dot_)local(_dot_)lan>
Message-Id:
<200110290051(_dot_)f9T0p5915862(_at_)reader(_dot_)local(_dot_)lan>
Yes. You can get rid of all the lines that start with "procmail:" by
commenting out the the "VERBOSE=yes" line. You should really only need
VERBOSE for debugging.
I want those lines to examine what is happening with certain spam
catching recipes. Adjusting regexp etc. Thats what my awk script
will do. Pluck those lines from the log so I can see at a glance what
has happened with a certain message.
[...]
:0: c
Ah, no. That means that the lock file is named "c". The second colon has
to come AFTER the flags, as in
:0 c:
But that's not what you want here anyway; you'd need a global lock with
the LOCKFILE variable. Probably, though, it would be easier just to turn
off logging of the backup copy:
Thought it might be all wrong. But at least I see now how the `:'
lockfile thing works.
:0 c
{
LOGFILE # No logfile, stop logging in forked copy
:0
backup/.
}
But that would give the wrong results. What is causing me problems is
the fact that stuff gets logged differently at the `c' part. Making
it hard to design scripting that can snatch a single messsages log
entries.
I'm trying something like this:
Leave the backup recipe in its original form and aim logging somewhere else
before it, back on after.
LOGFILE="OLD_FILE" <== near top of .procmailrc
[...]
LOGFILE="NEW_FILE"
:0 c
backup/.
LOGFILE="OLD_FILE"
Seems to work in my experiments but that is only with a few pieces of
mail. Seems to remove logging for the backup recipe and that means
the rest give a formatted log with regular occurence of message id
date etc. And still have a log of the backup action if needed.
Do you see a problem with that technique? Unthought of things that
will bite me when hundreds of messages come through?
[...]
I do have something similar shown in my original post I think
Yes; I was suggesting that you change it.
LOG=`date +"%b %d %T %w"`
[...]
LOG="`date +'%b %d %T %w'`
"
Oh, I see now. Sorry I didn't pick up on the double quote
positioning at first.
But it seems it doesn't get printed in a regular dependable way
either.
I don't know why that would be the case, so you might want to describe the
situation in more detail.
I didn't mean `irregular' in the sense of an error or bad performance.
My (log scanning) script needs to look for a start flag where it
begins to stuff lines of the log into an array. It then looks for the
specific m/id I've fed it. Then it looks for an end flag. Which
seems like it needs to be m/id but doesn't have to be for the script
to work.
Once all three states are met, the script will unwind the array and
print the saved lines, all log entries for the message with that
specific m/id.
You hit on what I mean when you say `date` will be first from any
message delivery. But the backup recipe is a copy so it logs the date
differently. Or maybe not at all. Hard to see the pattern in this log
output. And it makes the log scanning script harder to write. If I
used the date as the starting point, then the log messages from the
backup script would also get plucked up since no date is logged there.
And the END flag (Message-id) is missing too.
The head of "NEW_FILE" described above shows no date being logged
at the backup recipe. But is everywhere else.
procmail: Assigning "LASTFOLDER=backup/1"
procmail: Opening "backup/1"
procmail: Acquiring kernel-lock
From nobody Sat Oct 27 21:38:12 2001
Subject: Re: VIM 6.0: Is this a bug?
Folder: backup/1 1075
procmail: Assigning "LOGFILE=/home/reader/projects/proc/.log"
procmail: Opening "/home/reader/projects/proc/.log"
Also you can see the regular (OLD_FILE) log being reassigned at the end of
logging for that message.
Seems just removing the odd ball backup recipe log entries from
the main log will solve this for me. And greatly simplify my
scripting chore.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail