Discussion:
Problem assigning to and testing a variable
Donald E. Hammond
1998-01-05 00:19:28 UTC
Permalink
I want to forward copies of selected messages to my work address,
and one of the tests is the time it is received. I am having
trouble with the assignment and testing of DAY and HOUR variables.

I'm testing this at home with procmail v3.10 1994/10/31, but it will
be run at my account at the ISP using procmail v3.11pre5 1997/04/03.
(I know these are old. I'm working on getting them updated.) What
I have so far is getting delivered properly, but the logs indicate
it's not without some problems. This is what I have in the rc file
used to test this stuff at home:

PATH=/home/deh/bin:/usr/local/bin:/bin:/usr/bin
DEFAULT=/var/spool/mail/deh
PMDIR=$HOME/Mail
INCLUDERC=$PMDIR/.procmail_testrc
LOGFILE=$PMDIR/procmaillog
LOGABSTRACT=all
VERBOSE=yes #change to yes for debugging
DAY=`date +%a`
HOUR=`date +%H`
NL="
"
:0
* ? test $HOUR -gt 12
{
LOG=" $HOUR > 12 $NL"
:0:
$PMDIR/12+
}

:0
* ? test $HOUR -le 12
{
LOG=" $HOUR =< 12 $NL"
:0:
$PMDIR/12-
}

A test message sent around 5:20p ends up with the following log
entries. The assignment to $DAY and $HOUR fail the first time
through, followed by a fail of 'test' because the variables
don't have a value. Then it tries it all again, and everything
seems to work ok.

procmail: Assigning "LOGABSTRACT=all"
procmail: Assigning "VERBOSE=yes"
procmail: Executing "date,+%a"
date: write error: Bad file number
procmail: Assigning "DAY="
procmail: Executing "date,+%H"
date: write error: Bad file number
procmail: Assigning "HOUR="
procmail: Assigning "NL=
"
procmail: Executing " test $HOUR -gt 12"
/bin/bash: test: -gt: unary operator expected
procmail: Program failure (1) of " test $HOUR -gt 12"
procmail: No match on " test $HOUR -gt 12"
procmail: Executing " test $HOUR -le 12"
/bin/bash: test: -le: unary operator expected
procmail: Program failure (1) of " test $HOUR -le 12"
procmail: No match on " test $HOUR -le 12"
procmail: Assigning "LOGFILE=/home/deh/Mail/procmaillog"
procmail: Opening "/home/deh/Mail/procmaillog"
procmail: Assigning "LOGABSTRACT=all"
procmail: Assigning "VERBOSE=yes"
procmail: Executing "date,+%a"
procmail: Assigning "DAY=Sun"
procmail: Executing "date,+%H"
procmail: Assigning "HOUR=17"
procmail: Assigning "NL=
"
procmail: Executing " test $HOUR -gt 12"
procmail: Match on " test $HOUR -gt 12"
procmail: Assigning "LOG= 17 > 12
"
17 > 12
procmail: Locking "/home/deh/Mail/12+.lock"
procmail: Assigning "LASTFOLDER=/home/deh/Mail/12+"
procmail: Opening "/home/deh/Mail/12+"
procmail: [7609] Sun Jan 4 17:17:16 1998
procmail: Unlocking "/home/deh/Mail/12+.lock"
From deh Sun Jan 4 17:17:14 1998
Subject: procmail test 9
Folder: /home/deh/Mail/12+ 361
procmail: Notified comsat: "***@1356:/home/deh/Mail/12+"

When this is working ok, I won't need both the -gt and -le tests.
This is just for testing purposes here. What obvious problem
am I missing this time?

Thanks.

- Don
David W. Tamkin
1998-01-05 04:17:15 UTC
Permalink
Donald Hammond wrote ... well, we all saw his post.

My first comment is that not all versions of date honor the %-escapes,
and that could explain why these assignments:

| DAY=`date +%a`
| HOUR=`date +%H`

are failing. But I'm baffled why the whole rcfile is getting run twice.
What exactly is in the INCLUDERC that is called?

Regardless, if Donald's incoming mail gets From_ lines, he's better off get-
ting the arrival timestamp from there than by forking a program like date,
and once he gets it he can test its value with procmail's scoring rather than
by using "test" (which at best runs a /bin/test binary, at medium forks a
shell because there was no /bin/test found at compilation, and at worst runs
a /bin/test shell script).

NL="
"
:0
* ^^From .* \/[012][0-9]:..:
* MATCH ?? ^^\/..
{ HOUR=$MATCH }

# If your version of procmail doesn't allow you to re-extract from $MATCH
# later in the same recipe, substitute this:
#
# :0
# * ^^From .* \/[012][0-9]:..:
# { HOURMINUTE=$MATCH }
# :0
# * HOURMINUTE ?? ^^\/..
# { HOUR=$MATCH }

:0
* $ -$HOUR^0
* 13^0
{ # midnight to 12:59:59 PM
LOG=" $HOUR =< 12$NL"
:0:
$PMDIR/before1pm
}
:0E
{ # 1 PM to 11:59:59 PM
LOG=" $HOUR > 12$NL"
:0:
$PMDIR/1pmorlater
}

In truth, if he hadn't wanted to log the hour (after all, when one reviews
the logfile, it's there in the From_ line of the logabstract), I'd have
recommended simply this:

:0:
* ^^From .* (0.|1[012]):..:
$PMDIR/before1pm
:0E:
$PMDIR/1pmorlater

Finally, Don, are you really sure you want to cut off at 1 PM and not at
noon? If you work from 9 AM to 5 PM and get most of your mail from others at
your company, then 1 PM is the middle of the workday, so maybe you really do
mean to mark the cutoff at 1 PM.
Guy Geens
1998-01-05 17:51:57 UTC
Permalink
Donald> :0
Donald> * ? test $HOUR -le 12

I think you need to write it like this:

* ? $ test $HOUR -le 12

The `$' at the start tells procmail to expand variables in the
condition line.

This would be a bug in 3.10, as variables should be exported to the
child's environment by default.

Donald> {
Donald> LOG=" $HOUR =< 12 $NL"
Donald> :0:
Donald> $PMDIR/12-
Donald> }
--
G. Geens - Home: <***@iname.com> - Work: <***@inetgate.capgemini.nl>
``Normally, I'm white and fluffy''
David W. Tamkin
1998-01-06 13:22:29 UTC
Permalink
Guy Geens suggested to Donald Hammond,

| I think you need to write it like this:
|
| * ? $ test $HOUR -le 12
|
| The `$' at the start tells procmail to expand variables in the
| condition line.

That should not be necessary in an exitcode ("* ? command") condition.
It is for regexp (and negaated regexp) conditions.
Donald E. Hammond
1998-01-07 03:17:23 UTC
Permalink
On Sun, 4 Jan 1998 22:17:15 -0600 (CST),
***@wwa.com (David W. Tamkin) writes:

First, my apology for the tardy response to your's and Guy Geens
thoughtful help. It's been (unexpectedly) two days since I got
mail, and this was most helpful.
Post by David W. Tamkin
Donald Hammond wrote ... well, we all saw his post.
My first comment is that not all versions of date honor the %-escapes,
| DAY=`date +%a`
| HOUR=`date +%H`
are failing. But I'm baffled why the whole rcfile is getting run twice.
What exactly is in the INCLUDERC that is called?
Although your better solution(s) make it a moot point, my version
of date (GNU sh-utils 1.12) does honor the %-escapes. Whether or
not the ISP's version does is another matter -- and one which has
bit me in the past.

Regarding the rc file being run twice: I goofed. What I posted
*was* the INCLUDERC. The $HOME/.procmailrc simply sets up the
environment and INCLUDES this one. I inadvertently placed the
INCLUDERC statement in this file (including itself again) when
it was created. When I eliminate that statement, it works
without error. Sorry.
Post by David W. Tamkin
Regardless, if Donald's incoming mail gets From_ lines, he's better off get-
ting the arrival timestamp from there than by forking a program like date,
and once he gets it he can test its value with procmail's scoring rather than
by using "test" [...]
I honestly thought about procmail's scoring for this, spent some
time with the procmailsc man page, then decided to revert to
something I *thought* I could handle. I've collected a lot of
scoring examples from this list, and I'm not dense (although I
guess I've yet to prove that here), but I just don't get it ...
yet.
Post by David W. Tamkin
In truth, if he hadn't wanted to log the hour (after all, when one reviews
the logfile, it's there in the From_ line of the logabstract), I'd have
$PMDIR/before1pm
$PMDIR/1pmorlater
Well, this is the answer. The logging was not intended to be
carried over into the implementation. (No, that wasn't clear
either.) It was just part of my overly cautious testing (and
curiousity) to make sure that it was working as intended and
not simply by accident.
Post by David W. Tamkin
Finally, Don, are you really sure you want to cut off at 1 PM and not at
noon? If you work from 9 AM to 5 PM and get most of your mail from others at
your company, then 1 PM is the middle of the workday, so maybe you really do
mean to mark the cutoff at 1 PM.
Nope. More misleading information. This was just a random
choice used for testing. Someday I'll learn to pose the
questions correctly *and* include the correct information.
It is a testament to your abilities that you can provide the
correct answer(s) to the wrong questions. ;-)

The following is what I'm going to try.

:0
* ^(X-Loop|X-Mailing-List):.****@informatik
* ^(To|cc):.****@informatik
{
{ # from Sun 5:00p to Fri 4:59:59p forward a copy to work
:0 c
* ^From .*\/ (Sun .* (1[789]|2.):..:|(Mon|Tue|Wed|Thu) \
|Fri .* (0.|1[0-6]):..:)
! ***@fujisec.com
}
:0:
$DEFAULT
}

Again, thanks for the help.

- Don
David W. Tamkin
1998-01-07 15:58:25 UTC
Permalink
Donald Hammond followed up,

| Although your better solution(s) make it a moot point, my version
| of date (GNU sh-utils 1.12) does honor the %-escapes. Whether or
| not the ISP's version does is another matter -- and one which has
| bit me in the past.

The question is which version of date is showing up first in $PATH on the
machine where procmail is running, and I wasn't sure it was one that groks
the escapes.

| It is a testament to your abilities that you can provide the
| correct answer(s) to the wrong questions. ;-)

Thank you ... ?

| The following is what I'm going to try.
|
| :0
| * ^(X-Loop|X-Mailing-List):.****@informatik
| * ^(To|cc):.****@informatik
| {
--> { # from Sun 5:00p to Fri 4:59:59p forward a copy to work
| :0 c
| * ^From .*\/ (Sun .* (1[789]|2.):..:|(Mon|Tue|Wed|Thu) \
| |Fri .* (0.|1[0-6]):..:)
| ! ***@fujisec.com
| }
| :0:
| $DEFAULT
| }

And it won't work. You have a left brace hanging out of nowhere with no re-
cipe to open it (where I marked the arrow). Also, I gather that the second
condition is to weed out a lot of the spam blind carboned to this list, so
you might be better off with ^TO (or ^TO_ if your version of procmail sup-
ports it) there, and you have an extraction operator where you're not using
the resultant $MATCH. Finally, just in case something gets hosed and there
is yet another ^From_ line buried in the header, I'd anchor to the start of
the head rather than only to the start of a line. So then we'd have this:

:0 # Use ^TO if you don't have ^TO_
* ^X-(Loop|Mailing-List):.****@informatik
* ^***@informatik
{
# from Sun 5:00p to Fri 4:59:59p forward a copy to work
:0 c
* ^^From .* (Sun .* (1[789]|2.):..:|(Mon|Tue|Wed|Thu) \
|Fri .* (0.|1[0-6]):..:)
! ***@fujisec.com

:0: # Are you sure you don't want a special folder for the list?
$DEFAULT
}

I'd do one thing differently as a matter of personal taste; I'd list the
shorter part of the week rather than the longer part in the forwarding test:

# from Sun 5:00p to Fri 4:59:59p forward a copy to work
:0 c
* ! ^^From .* (Sat |(Fri .* (1[789]|2.)|Sun .* (0.|1[0-6])):..:)
! ***@fujisec.com

Continue reading on narkive:
Loading...