On Sun, 21 Nov 1999 07:04:51 -0800 (PST), Dallman Ross
<dman(_at_)netcom(_dot_)com> wrote:
I don't get the parens, though, in the first condition line. I see
what it's doing, but have never seen these parens before. You use
them above with "($)" also. I think after experimenting that the
(.*) means real parens in the header. (Your line is close but not
perfect in order to match the reality of what I get.) But I still
don't know why it's above with "($)".
Uh, sorry, no real reason, they don't do anything and are basically
completely useless. The habit of gratuitously parenthesizing some
things is a good one, though, but it shouldn't be displayed in an
example like this.
(Why is it good? Because you tend to forget to put in the parens when
you do need them -- as in, changing ".*" to "complicated regex" and
adding a * at the end, not realizing that "complicated regexp" needs
to be parenthesized in order for the * to have the intended scope,
until you notice that your new recipe doesn't work like you intended,
and spend three days without food or drink before you realize that
this "mysterious bug" was just a case of freaking missing parens. :-)
Still unanswered is whether, after all that work, the variables I
save will work later in the rcfile. So far I can't get them to!
And do I use braces to save $MATCH to other variable names? It
appears that is the only way?
Not sure if I understand this question. Variable assignments will hold
until the end of the current Procmail run but MATCH may of course be
overwritten by subsequent grabbing recipes, in which case you need to
copy it to another variable if you want to remember its value.
The braces are not strictly necessary, in the sense that you can
certainly put the assignment outside of the braces:
:0 # incidentally, another "gratuitous" paren which is very necessary
* ()\/moo
{ }
MOO=$MATCH
or even
:0c:
* ()\/moo
moo
MOO=MATCH
So the primary purpose of the braces is that an action without braces
(or a pipe, or a bang) is always a save to a file, and if you want the
action to be something else, it needs to be in braces. One of the
classical examples of a minimalist action in braces is a variable
assignment, but braces can, of course, by themselves, contain
arbitrarily complex recipes.
( whatever ) | sendmail -oi -t
I get bounces. The server says that "-oi" and "-t"
are not valid addresses. I don't get it. This
Use $SENDMAIL which is what ! expands to. Probably just "sendmail"
without a path invokes some local wrapper or cheap imitation, while
$SENDMAIL with a full path invokes a different program altogether,
which is (or is better at pretending to be) a true Sendmail.
No, that's not the answer, unfortunately. I do use $SENDMAIL. I was
just writing in shorthand. But I misspoke: It's only bouncing "-oi"
and not "-t".
I'd still be willing to bet that the truth behind what you're seeing
is that what you are executing simply isn't a standard Sendmail, and
that's why it doesn't grok -oi. So you should be using
| $SENDMAIL $SENDMAILFLAGS [ -t or addresses ]
instead of
| $SENDMAIL -oi [ -t or addresses ]
or even
| sendmail -oi [ -t or addresses ]
because that way, Procmail takes care of using the options which are
right for your poor Sendmail clone.
Final problem (of this mail): fileperms are stuck
public (rwxr-xr-x) and I can't change them.
UMASK = 077
has absolutely no effect. Why would that be?
Can't help with that one, I'm afraid. You should be aware that
UMASK affects the creation of new files only, though. It cannot
change the mode of a file which already exists and which you
append to.
Yes, I knew that. It's not working in any case. :-( I'd hate to
have to call chmod from the shell just for such a silly thing.
(Can you check in the log whether UMASK is set to what you think it
is, just before the action?
LOG="me here, just a quick note: UMASK's value is $UMASK
"
with the familiar newline before the closing quote.)
/* era */
--
Too much to say to fit into this .signature anyway: <http://www.iki.fi/era/>
Fight spam in Europe: <http://www.euro.cauce.org/> * Sign the EU petition