Re: Including a shared recipe in .procmailrc

dattier(_at_)wwa(_dot_)com (David W. Tamkin) writes:
> Catherine Hampton asked,
<deleted>
> | And are there any special considerations/pitfalls
> | in the format and commands in the recipe file?  Thanks!
>
> Just make them as generic as possible.  Users may have to set some variables
> before and after: for example, if the included rcfile assumes that certain
> information will be in $THIS and it sets $THAT to the information the user
> needs, the user has to assign $THIS before the INCLUDERC statement and then
> do something with $THAT afterward.
To comment on this last bit, if you do expect people to pass in info
via variables then you should attempt to the phrase the recipes such
that failure to set the variables to sane values does not result in
lost mail.  For example, if you expect people to pass in a filename
then it's probably a good idea to wrap the entire recipe in something
like:

:0
* FILENAME ?? .
{
    # The recipe(s) go here -- FILENAME is definately set to *something*.
    ...
}
:0E
{
    LOG = "*** WARNING: whatever includerc this is was invoked without setting
FILENAME first.  All the recipes are therefore being skipped.  That INCLUDERC
line is doing nothing in your .procmailrc.
"
}


If a filename is being passed in, and you expect to change MAILDIR in the
recipe, then you may want to make absolute (absolutize?) the filename:

# Is it set?
:0
* FILENAME ?? .
{
    # Is it abolute?
    :0
    * ! FILENAME ?? ^/
    { FILENAME = "$MAILDIR/$FILENAME" }

    # Okay, we can now change the MAILDIR, but we should also restore the old
    # when done.
    OLDMAILDIR = $MAILDIR

    # recipes go here, including changes to MAILDIR
    ...

    # Restore MAILDIR
    MAILDIR = $OLDMAILDIR
}
:0E
{
    LOG = "*** WARNING: whatever includerc this is was invoked without setting
FILENAME first.  All the recipes are therefore being skipped.  That INCLUDERC
line is doing nothing in your .procmailrc.
"
}


The idea to program defensively.  Got it?

Philip Guenther