Philip Guenther took on some of Jim Dennis's questions (most of which were
answerable with "Yes, Jim, you have it right"). I'd like to comment briefly
on one of Jim's questions and then get to a couple things Philip went into:
| > * H ?? !^TO_whoever
Is that syntax valid? I've never tried it, always using,
* ! H ?? ^TO_whoever
I suppose it ought to work, but I've never noticed anyone using it before.
Anyhow, to Philip's text:
| :0
| * $ ^X-Homedir: *$HOME\$
| |something
|
| The trailing dollar is backwhacked to keep procmail from trying to do
| variable interpolation. After the expansion it will look like a naked
| dollar and will match end-o'-line.
You don't need to backwhack the trailing dollar sign for that. [nothing]
is not a valid variable name, so a trailing $ will survive unchanged under
interpretation by a leading $. $something will be replaced with the value
of $something only if something is a valid name for a variable.
There is one easy way around the confusion: with or without $ interpreta-
tion, ($) always represents a newline and [$] always means a literal dollar
sign in the text. Since ")" and "]" are not valid characters in the names
of shell variables, those regexps are not affected by $ interpretation.
If you're looking for the string "$50" it's probably a heck of a lot easier
to use
[$]50
than to worry about needing
\$50
when there is no $ interpretation and
\\\$50
when there is, especially if you make changes to the condition that mean
adding or removing the interpretation level.
One caution about $ interpretation, though: when you're using it, graves
(backticks, these things: ``) outweigh brackets and parentheses, so any
accents graves that represent literal accents graves have to be escaped (or
backwhacked as Philip put it).
| * HOME ?? $ ^$MATCH(/|\$)
Again, that dollar sign near the end doesn't need to be escaped to survive $
interpretation, since the character following it is a right parenthesis,
which is not valid in a variable name. The same is true of the left paren-
thesis, and Philip counted on that when he wrote "$MATCH" and not "${MATCH}".
Personally, I'd write the regexp like this,
* HOME ?? $ ^$MATCH(/.*)?$
[or * $ HOME ?? ^$MATCH(/.*)?$ ]
because my brain is wired such that "if the line doesn't end there, the
rest of it continues with a slash" suits my logic better than "the next
character is either a slash or the end of the line," with which Philip
feels more comfortable. The two are, of course, equivalent.
| It appears from the source that the specified program will have
| whatever would have been grepped at it's standard in. You could
| even say:
|
| :0
| * HOME ?? /some/program/that/wants/$HOME/on/its/stdin
| ...etc
Wouldn't that need to be
* HOME ?? ? /some/program/that/wants/$HOME/on/its/stdin
^^^
Otherwise, you'd be checking whether the value of the variable $HOME contains
the string "/some/program/that/wants/
HOME/on/its/stdin". If your home directory name includes that string, embed-
ded newline and all, shoot your sysadmin, please.
Anyhow, my understanding from somewhere in the man pages is that the H and
B *flags* do not affect programs called in exitcode conditions; they have the
entire incoming text at stdin (unless you use "H ??" or "B ??" on the condi-
tion line), just like programs called in VARIABLE=`program -opts args` as-
signments.