On Mon, 16 Aug 1999 17:38:50 -0700, "Daniel R Sullivan"
<dan(_at_)wildtangent(_dot_)com> wrote:
http://www.sullivantech.com/sqlsupport.tar.gz
Couple of quick comments:
You have shell=/bin/sh but Procmail's variable name facility is case
sensitive, you mean SHELL=/bin/sh
You use formail to grab SUBJECT and FROM, but you can instead do
something like this:
:0 # whitespace between [ and ] is one tab and one space, in all places
* ^From:[ ]*\/[^ ].*
{ FROM=$MATCH }
:0
* ^Subject:[ ]*\/[^ ].*
{ SUBJECT=$MATCH }
Avoiding external programs is desirable, this should be quicker and
perhaps more robust (doesn't have to rely on formail being installed
in user's PATH) although there are some minor differences (FROM will
be entirely unset instead of empty if the From: header doesn't match
the pattern we match in the condition. No practical difference that I
can see).
In the calls to the Perl scripts, you should probably quote $FROM and
$SUBJECT on the command line, no? That way the entire SUBJECT will be
$ARGV[0] so you don't have to guess how many elements @ARGV has (not
that it's necessary, you could just plonk all of @ARGV but it's easier
to have it all in one scalar, isn't it? A side effect of not quoting
is that you lose any whitespace formatting without the quotes. But if
this is desirable, you can certainly $ARGV[0] =~ s/\s+/ / in your Perl
script).
Not sure what the parsef script is suppsed to accomplish, it doesn't
seem to do anything that couldn't simply be done straight from
Procmail (and again the unquoted ARGV processing is clumsy, do you
need it to be exactly ten tokens, with extra spaces even if some of
those ten are missing?)
I'd say what you are trying to do could be done like this in Procmail:
:0c:$HOME/fromt.lock # yes, locking is important
| formail -zxFrom: >>$HOME/fromt
and the whitespace thingy in Perl is certainly more natural like this:
print join (" ", @ARGV); # or @ARGV[0..10] if you insist on ten elements
but I don't really see why you would need to go via Perl for this.
(If you want $FROM to be set for other reasons, you can of course say
# FROM=$MATCH from earlier
LOCKFILE=$HOME/fromt.lock # locking is still important
DUMMY=`echo "$FROM" >>$HOME/fromt`
LOCKFILE
but I don't see you using fromt for anything else than as a help file
for the support script.)
The support script receives the entire message on standard input
anyhow, so the fidgeting with temp files is counter-productive. Just
do something like
# Set SUBJECT and FROM as proposed earlier
:0b
| support.pl
and then in support.pl,
$From=$ENV{"FROM"}
$Subj=$ENV{"SUBJECT"} # instead of $ARGV trickery
$Inbox = <>; # slurp message body from standard input
That way, you don't need any temporary files at all. (The removal of
the temporary files from within support.pl looks kind of weird as
well, what if you ctrl-c this script before it gets to removing the
temp files, what will then happen the next time you run it?)
Some locking issues still preoccupy me, does Perl's dbm routines take
care of concurrency issues if you have two messages arriving roughly
at the same time? If not, you should use locking. The FAQ attempts to
explain locking to some extent, have you looked at that? (The URL is
<http://www.iki.fi/era/procmail/mini-faq.html>.) The basic idea is to
use a file to tell other instances of Procmail that "whoa, I'm in the
middle of something here, can you come back and try again in a minute".
Hope this helps,
/* 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