procmail
[Top] [All Lists]

Re: Locking

2001-04-22 07:58:13
On 22 Apr, Paul M Foster wrote:
| On Sun, Apr 22, 2001 at 01:38:23AM -0400, Don Hammond wrote:
| 
| > On 21 Apr, Paul M Foster wrote:
| 
| <snip>
| 
| > | 1. Apparently, when piping through, say, formail, you don't need to use
| > | a lockfile. Why? (Of course, I don't know why you'd use a lockfile in
| > | the first place.)
| > 
| > A pipe to to formail isn't writing to any regular files on disk.
| >  
| 
| Not sure I agree. If I don't do something like:
| 
|| formail ... >> $DEFAULT
| 
| the output from formail seems to disappear. So in this case, I'm writing
| back to the spoolfile, which is a regular file on disk.

Well in that case you want a lockfile on the recipe. My language was
imprecise and should have been something like "formail (or anything)
used as a filter isn't writing to any regular files".  I have no idea
what to say about your trouble without the list seeing more of the
recipe(s) causing you problems. The only guess I have is you might be
using formail with a "c" flag, not delivering the copy/clone, and it
appears as though the formail output is disappearing. But without
seeing the actual recipes it's hard to say.

| > | 2. Under certain circumstances, you would use the "f" flag in the
| > | beginning of a recipe to indicate that you want procmail to filter the
| > | header or whatever. But if I use a piping recipe (e.g. | formail ...),
| > | why would I need to _tell_ procmail I'm filtering the email, since the
| > | pipe automatically indicates some sort of filter? Perhaps more
| > | important, how does procmail handle things internally differently if you
| > | tell it to filter, versus when you don't?
| > 
| > Because your assumption that a pipe automatically indicates a filter is
| > incorrect.
| > 
| >   :0:
| >   * spam condition(s)
| >   | gzip -c >>$SPAM.gz
| > 
| > This is a delivery not a filter. ;-)
| >  
| 
| Alrighty, then I don't know what a filter is. I would have assumed that
| anything is a filter when email is piped to it. It seems by your answer
| that a "filter" would be something which is "non-delivery". According
| to the man page, that's only things which 1) give the email back to
| procmail for handling, 2) start a nesting block, or 3) recipes that use
| the "c" flag. Is this correct? If so, some of the FAQ stuff I've seen
| seems incorrect. Often when formail is used, the "f" flag is also used.
| And if you don't want to make formail output disappear, you have to dump
| it back on the spool or give it back to procmail (which would, of
| course, make it non-delivery).
| 

This is the way I think of it. I trust others will jump in if I've got
it wrong.  The procmailrc man page says there are two kinds of
recipies: delivering and non-delivering. When a delivering recipe
matches, the mail is delivered and processing of rcfile(s) ceases. When
a non-delivering recipe matches, processing of the rcfile continues
after the action is executed.  In that context, when the man page
explains the usage of different recipe flags further down and uses the
term "filter", I think of it as a non-delivering recipe. 

Your confusion seems to stem from the use of the "f" flag, telling
procmail to consider the pipe a filter. The reason the "f" flag would 
be necessary is because procmail has no way of knowing when you send the
message to a pipe whether the message is being delivered or not. The f
flag tells procmail specifically that the program is not delivering the
message and to continue processing the rcfile.  Maybe an example will
help.

:0
* condition identifies spam
{
  :0 fh:
  | gzip -c >>SPAM.headers.gz

  :0:
  | gzip -c >>SPAM.gz 
}

Maybe not the most likely of examples, but I think it illustrates what
you seem to be questioning.  First, both recipes inside the block
request a lockfile because a regular file is written to. The first one
has the "f" (filter) and "h" (headers) flags because I want to save the
headers to a separate file, and continue processing. If it did not have
the "f" flag on it, procmail would consider the message delivered and
the second recipe would not execute.

Hope that helps.

Don Hammond



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>