Dallman Ross wrote:
On Thu, Jun 22, 2006 at 04:19:34PM -0700, Don Russell wrote:
Dallman Ross wrote:
REPLYCC = `formail -zx To: -zx Cc:`
i.e. you mentioned
REPLYCC = `formail -zx To: -zx Cc:`
....................................^
\
Watch out! That's a backtick on the end, not a single-quote.
is better than
REPLYCC=| formail -zx "To:" -zx "Cc:"
due to a potential bug...
I assume you mean REPLYCC=`formail...` (no space before = as per
your earlier message)
No, I meant it the way I typed it. The space is not significant there.
It's only significant in that one syntax that you had trouble with.
Ah... another source of confusion.... so the blank is only significant
on an assignment ACTION statement... sheesh. :-)
You can of course take the spaces out, if you want. I like 'em in,
but that's a personal preference.
Yes, I like them too.... which is what lead me into temptation and used
one where I shouldn't.... :-)
Also, I'll add that I tested what I posted.
but also, I read the pipe character as being the "current message
being processed"... makes sense.. that gets piped to stdin of
formail.... (or whatever the first program after the | )
It makes sense, sure. But therer's a bug in the procmail source,
is all. If you want to blow away unknown bytes of memory from
the current run, be my guest ... :-) (Or find a patch. The
procmail I use is patched.)
OK... I'm just trying to make sure I'm understanding the concepts
correctly.... if the concept is correct, but there is a bug... a work
around is great. My procmail version 3.22-16.2.1. How can I tell if I
have this patch applied? Or is the patch not for general consumption?
But what about REPLYCC=`formail ...` what does formail see on
stdin in that case? I expect it would see end-of-file. i.e. no
input...
I don't really follow your question. This is not a recipe I've
used, but a variable-assignment statement. Inside rcfiles can
go any of: (1) recipes (which start, modernly, with ":0" and must
have an action line); environment variables; and comments.
Well, VAR=|program very clearly indicates that "program" will get the
current message on stdin, via the pipe...
but VAR = `program` does not have that "self documenting look".
Since VAR = `formail ...` assigns the correct value to VAR, then formail
in this case MUST be reading the current message.
It's OK.... I think I need to pour over the man pages some more.... I
find my "procmail companion" book a little vague and lacking in detail..
great for an overview, but not one of my favorite reference manuals. :-)
See the first few lines of 'man procmailrc'.
The rcfile can contain a mixture of environment
variable assignments (some of which have special
meanings to procmail), and recipes.
There are many ways to skin a cat, as they say. A recipe
that sends the message to a pipe is nice. Setting a variable
that way is theoretically really nice; one, it's a non-delivering
recipe, so we don't need a c-flag or other trick to keep the
message moving further down the rcfile after. And, two,
we can send just the header (as you were doing) or just the
body, or whatever, wich is, well, nice. But the way I did
it also works. It does send the whole message through, however.
I also gather that REPLYCC=| ... must be an action line, after a
: line (with or without conditions), while REPLYCC=`formail...`
must NOT be an action line, otherwise I end with the message
being delivered to a mailbox called REPLYCC=...
Correct.
So, as a rule of thumb.... if I have a construct like
:0 h
SOME_VAR=|something...
it is better to simply omit the : line altogether and code
SOME_VAR=`something...`
Is that right?
That's what I'm saying, yes, unless you fix your procmail
binary with a patch so you can revert to your way.
The nice thing about
:0 h
VAR=| ....
Is only the headers get passed, correct?
In my case, the messages I'm handling may be several megabytes of
attachments being processed, so if the entire message body is processed
that could be wasteful. OTOH, if formail is being told to extract
specific headers, I expect it to close stdin when it determines the
headers have ended.... so, no harm when the target program is formail
for header extraction. Syntactically I prefer the VAR = `formail...`
method anyway. I would rather use a single line than two lines of code
to accomplish the same thing. :-)
Btw, I'll admit to doing it the "dangerous" way sometimes (on
unpatched binaries). But nobody but me relies on that syntax.
Generally, if you shoot a BB at your memory matrix nothing bad
will happen. :-)
Generally speaking, I try to avoid shooting myself in the foot. (Or in
the memory in this case) :-)
Thanks for all your help/explanations... I really appreciate it.... I've
made a lot of progress today with your help.
Cheers,
Don
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail