Tony Nugent wrote,
| Then I can assume that procmail treats INCLUDERC files like
| subroutines, with control going back to the caller.
Yes, if procmail gets to the end of $INCLUDERC without final delivery, it
returns to the previous rcfile immediately after the INCLUDERC assignment.
INCLUDERC's can be nested and even called recursively: however, each open
INCLUDERC uses a file descriptor, so the nesting or recursion depth is
limited by the kernel's maximum permitted number of open file descriptors.
Alan Stebbens had told Tony,
| > This of the following condition:
| >
| > * SOMEVARIABLE ?? .
| >
| > as a procmail colloquialism for the statement:
| >
| > if SOMEVARIABLE is set
Not exacatly. That condition means "if SOMEVARIABLE contains at least one
character that isn't a newline." If SOMEVARIABLE is set and null, or if
it is set but contains nothing but a newline or a bunch of newlines, that
condition will fail.
It is very rare to set a variable to null or to a newline or to a string
of nothing but newlines, so almost any set variable will pass the condition,
but if you *ever* have to test a variable for set or unset and accept a
set-but-null situation the same as set-and-non-null, here's the way:
* $ ! ${SOMEVARIABLE+!}
To reject it if unset or if null but still to accept it if it contains
only newlines, you have two available syntaxes:
* $ ! ${SOMEVARIABLE:+!} # note colon that wasn't in the previous one
or
* SOMEVARIABLE ?? .|^^.*$.*^^
In the second form, you need to make sure procmail is matching on an included
newline and not on the putative newlines that it puts around all variables
for its eternal egrep (so that ^ or ^^ will match at the beginning of the
variable and $ or ^^ will match at the end).