Edward Sabol quoted me,
| > * $ ^TO_$LOGNAME\+\/.*
and then actually asked,
| Um, why don't you just use $1?
Sabol declined to quote the rest of my suggested code; that was actually part
of an `E'lse brace; I resorted to looking after the plus sign only if $1 was
unset. The full suite may have appeared in a different post of mine, how-
ever, so when he was posting he might not have known that I was already con-
centrating on the case where $1 was unset. At any rate, if it is there, by
all means use it.
But he overlooks the situation where the suffix is not presented to the user
in $1. Not all setups are identical to his, and some of us don't receive the
information neatly packaged for us.
We don't all choose the MDAs for our sites. Some of us have to invoke proc-
mail from .forward or even a cron job (or worse, from .profile or .login) and
proceed with no available information about the envelope recipient; we have
to rely on the visible headers to throw our mail. We don't the information
as $1; we're freaking lucky if our systems deliver mail to us at all if it is
addressed to logname+suffix, and if they do, our only way to learn the suffix
is to extract it from the visible headers.
And that is why we need a backup plan when the information isn't in $1 but
could be found somewhere else.
He continued with this example:
| ARG = $1
|
| :0
| * ARG ?? ^^foo^^
| foo-folder
and noted,
| You can't test $1 directly, hence the assignment to ARG.
The assignment is needed for the condition, but I think that the action
line, since it is interpreted by procmail and not by a shell, could use
$1. For example:
ARG = $1
:0: # if the folders are plain files, we need a local lock
* ARG ?? ^^(foo|bar|gwippyhooch|tastykake)^^
$1-folder
ought to work. Of course, $ARG-folder is sure to work. (The variable or the
parameter will be expanded before determining the name of the local lockfile.)
DWT