On Wed, 16 Feb 2000, era eriksson wrote:
On Tue, 15 Feb 2000 14:41:09 -0600 (CST), Glen Lee Edwards
<GLEdwards(_at_)uswest(_dot_)net> wrote:
On Tue, 15 Feb 2000, Andrew Edelstein wrote:
On Tue, Feb 15, 2000 at 10:18:11AM -0600, Glen Lee Edwards wrote:
If you want concurrent Procmail processes to wait in line for their
turn, a lock is definitely the way to go. But yes, it would probably
be more correct if the list program itself did the locking; that way,
you can call it from the command line, too, without interfering with
whatever Procmail might be doing at the same time. A simple way to
accomplish that is to write a small wrapper which does the locking,
and call the wrapper instead of the real thing. (You can call it by
the same name as the real script, just put it in a directory which is
earlier in your -- and Procmail's -- PATH.)
I'll have to think about this one. The listserve program isn't run from
root, nor is the username the same as the program name (obviously), so all
mail to the program is aliased to the user first, then sent via
~/.procmailrc to the program. Since all mail must pass through procmail
first I would hope that I could use it to filter out one letter at a time
to the list. Using fork() immediately in the listserve program hopefully
helps keep a bottleneck from occurring in procmail.
# The following code checks for list id, moves Cc addresses to the
# To: field, spans a separate copy per list match found so letters
# can be cross posted, and lowercases list_id for file access
# match; then sends the letter to the listserve program.
I don't see the "separate copy per list match found", is that
something you had cut out? (Do you mean "spawns"?)
These are personal notes. Don't take "spawns" too literally. A copy is
created.
Each list has its own recipe in this section. I did it this way in case
someone would cross post to several lists on the server (hardly a perfect
solution, but it's working). If a match is found in the following recipe
a copy of the letter is sent to the listserve program, not the original.
This allows other recipes to check the original for cross-posted letters.
The drawback is that I always have a duplicate copy fall in Inbox (without
:0 c I only received a copy in Inbox if the system failed for some
reason) so I don't have a quick method of making sure the program is still
working correctly unless I manually check .procmail/log.
:0 c
* ^TO.*perl
{
:0 fwh
| perl -pe 's/(^To|^Cc)(.*)(perl.*?net)(.*)/To: \L$3\E/i;'
:0 aw: listserve.lock
| /deleted/path/to/listserve.cgi
}
A few minor comments ...
The ^TO.* pattern is basically always wrong. Either you want ^TO or
you want something else which may or may not involve .* but very
rarely do you need both together. ^TO is a "magical" macro which
contains a (better bounded) wildcard expression in itself.
Didn't know that.
Usually,
you actually want ^TO_ rather than ^TO (if you are running a fairly
recent [like, post-1995] version of Procmail).
My server is running an old version of RedHat Linux, which they've really
neutered. The man pages don't mention ^TO_, so I've stuck with ^TO to
play it safe. I'm using ^TO_ on my home PC.
Perhaps you should include the domain part of the address, too,
though. If somebody sends something to you with Cc: perl(_at_)cpan(_dot_)org or
even with Cc: perlers(_at_)example(_dot_)com your recipe will treat that
as an incoming list message as well. (Your current recipe with .*perl
would even match on To: superlative(_at_)yourdomain(_dot_)example(_dot_)net)
^^^^
So I'd recommend ^TO_perl(_at_)christianfamilies(_dot_)net\> for safety.
Good call. I'm learning this by trial and error. Some lists get pretty
snippy with posters so I don't normally ask for help unless it's broke and
I can't fix it.
The Perl lowercase-and-canonicalize thing is pretty neat. If it were
mine, I might still go out of my way to avoid running Perl for a
simple job like this, but I can't come up with something equally
succinct and elegant.
Perl isn't the perfect solution to all programming problems, but I've
found that it has a workable solution for most problems. Originally I was
going to add this section within the listserve program itself, but my
convoluted brain got lost in the forest, so I opted to do it in
.procmailrc instead. There are some side affects to using this system
that I need to deal with, but so far I'm running low volume lists, so the
obvious bugs haven't bit yet.
(There's a neat trick for lowercasing matches, by David Tamkin; it
involves matching against a "canonicalized" version of the strings you
expect to match, and use the \/ grab operator to grab the matched
canonicalized string. Don't worry if this description scares you -- I
guess it ought to. :-)
Only if it means I have to learn another programming language. {-_o}
... Best I can come up with off the top of my head is to do it in sed,
but sed's y/// operator is incredibly unwieldy. Or you could lowercase
everything with tr(1) and let the Lhord recognize his own -- to: can
perfectly well be written in lowercase (provided that your listserve
script tolerates that ;^)
Wouldn't be hard to make the necessary modifications.
and if the local part of your list's address
is all lowercase, that shouldn't be a problem either.
Has to be. Membership files, etc., are in /path/to/perl/members. I
insert the list name:
$path = "/path/to";
<deleted>
/^To: (perl|healing|mnnaz)/;
<deleted>
$list = $+;
<deleted>
open(MEMBERS,"$path/$list/members") ...
Thanks for your comments and suggestions.
Glen