Ari <wlotus(_at_)greatnorthern(_dot_)net> writes:
What I am trying to do, not being a computer person, is learn this system
and it's conventions so that I don't have to write it down all the time and
it would help serve as a mneumonic if things are explained.
Unlike pneumatic, mnemonic doesn't have a 'u'. (Try saying *that* five
times fast!)
So, here are my questions:
1.What does the * mean? the $ is an anchor, right?
Once you've started a recipe with the ":0" line, procmail needs some
way to tell when the conditions end and the action of the recipe has
arrived. To do this, the conditions are marked with a leading '*'. If
the line doesn't begin (ignoring whitespace) with a '*' then it's the
action. In the current version of procmail, blank lines and line that
just contain a comment are ignored when looking for the conditions and
the action.
The '$' means different things in the different places. At the
beginning of a condition (right after the '*'), it indicates that the
text of the condition should undergo Bourne shell style variable and
backquote expansion, then be reparsed as if the result was the original
condition. This allows you to have variables that contains pieces of a
large regular expression. If a condition has such a leading '$', then
'$'s in the condition itself are variable expansions unless escaped
with a backslash. If a '$' makes it through this expansion, or if
there was no such expansion, then a '$' is an end of line anchor and
matches a newline. Note that conditions can match multiple lines in
one match.
Also:
2. what is the difference between
:0
and
:0:
The latter requests that procmail use a locallockfile. In particular,
since there's no filename after the second colon, procmail will attempt
to figure out an appropriate locallockfile by examining the action. If
the action is to deliver to a Berkeley style (single file) mailbox, then
procmail will use a lockfile named by adding $LOCKEXT to the mailbox name,
where LOCKEXT contains ".lock" by default. If the action is a program
('|') action, then procmail will look at the command line for ">>". If
it finds one, it uses the next 'word' with $LOCKEXT appended again. If
there is no ">>" then procmail will complain:
Couldn't determine implicit lockfile from "whatever the action is"
and then use $LOCKEXT by itself as the lockfile. You should fix this if
it occurs, either by removing the lockfile it doesn't really need it, or
by specifying a more appropriate lockfile by hand after the second colon.
3.Another question that I have is how do you know where to put a space or not?
Is
:0D:
* ^Subject:.NET$
Junk
the same as -
:0D:
*^Subject:.NET$
Junk
Yes. For the most part, procmail ignores leading and trailing
whitespace, as well as whitespace inside the recipe start line. and
after the '*' that starts the condition. If there are 'flags' on the
condition, such as a leading $, !, ?, >, <, or "variable ??", then
white space among then and before the _real_ regexp is ignored. If a
line is continued, then leading whitespace is ignored on the
continuation.
How about if we turn this around. The only places that procmail *doesn't*
ignore whitespace are:
o) In the (optional) locallockfile name, where it causes the rest
of the line to be ignored and warning to be logged.
o) In the middle of a regexp on a condition line
o) In an action
Yes, I have already read the man files, but I am not a computer programmer
and some of the things seem kinda arbitrary.
procmail has evolved quite a bit since it first came out, and its
syntax is thus sorta strange in places, partially in the name of
backwards compatibility, partly to avoid ambiguity, and partly because
it seemed like a reasonable way to do things when Stephen (the author
of procmail) thought up a new feature.
Don't be afraid to try things before using them. When answering
questions on the list I'll sometimes be unsure on how procmail will
react to something, so I'll try it, either by putting it in my
.procmailrc and sending a message, then pulling it back out, or by
putting it in a separate file and invoking procmail on that will a hand
crafted email message right then and there. That's how I found out
that "whitespace in locallockfile causes warning". I tried it. It's
not like your computer will catch fire if you do something bad in your
.procmailrc. Just watch it really closely for a couple messages, try
some boundary conditions (empty message, empty header field(s), bad
return address, whatever), and if your recipe handles them correctly,
leave it in.
Of course, if you know C, you can always read the source, but that's
*not* for the faint of heart, as procmail's source has been bummed by
Stephen to be almost incomprehensible in places, though his comments
will usually carry you through, and can be hilarious in their own right.
I mean, just consider, in context, the "new ball" comment in misc.c...
Have fun using procmail!
Philip Guenther