LuKreme wrote on Saturday, January 18, 2003:
On Saturday, Jan 18, 2003, [. . .] dman(_at_)nomotek(_dot_)com wrote:
But we don't need echo, sed, or even date, anyway.
First off, you'd almost certainly want to use the From_
header to grab this info rather than the Date: one.
Maybe in general, but I thought it would be easier to grab it from
Date: (especially since i know I am dealing with GOOD mail here and I
did check the headers before I stared). Also, the From_
indicates when the mail arrived at my local machine. If my
connection is down that can vary by 6-12 hours (and once, three days).
I'd actually rather have the Date: in this case.
I don't agree that, in most any case, Date: is going to be better.
First of all, the variations in Date:, which, as someone has already
stated, *you do not control*, make it an uncertain thing to analyze
the way you have. The likelihood is much greater that there will
be nonconforming (to your algorithm) date headers than that the
very occasional delayed mail would bite you.
Second, as has already been stated, people are notoriously uncareful
about setting the dates on their personal computers. Do you want
mail to be filed erroneously for last year, next year, some year
before the Common Era, or whatever? The From_ header's date info
is at least as trustworthy as your mail host's clock; and the
format is perfectly consistent and predictable.
Here's some stuff from my genvars INCLUDERC that will get
you what you need (and more).
MMtable = "{ Jan:01 Feb:02 Mar:03 Apr:04 May:05 Jun:06
Jul:07 Aug:08 Sep:09 Oct:10 Nov:11 Dec:12 }"
:0 # 030110 () save tail-end of FROM_ in order to parse DATE
* $ ^^From .* \/$AWEEKDAY .+
Oh, that's clever! wouldn't it make more sense to do:
* $ ^^From .* $AWEEKDAY\/ .+
No. I want to save the value of $AWEEKDAY that the message contains,
not the table of seven possible weekdays that I have already amassed.
though? do you WANT the weekday to be part of $MATCH?
Yes, absolutely. I want the mail to tell me that today is Monday.
That was part of the point.
{ FROM_ = $MATCH
:0 # 021211 () find year in FROM_
* FROM_ ?? ()\/....^^
Mightn't that match "-0600" if the date is in "Thu May 2
09:45:18 2002 -0600" format? (oh, wait, never mind. That would
be seen as a 5 character word, right?)
Not only would it not do that for the reason you state, it would,
further,
not do that because the From_ line is never formatted that way. The
From_ line is consistent. It ends in a year. That is, your proposed
issue will never arise.
:0 # 021211 () find MM
* $ MMtable ?? ()\<$MONTH:\/[01][0-9]
I don't understand that syntax.
I am, basically, sliding the string I found somewhere above, which
I'd saved to $MONTH, across my MMtable to land on a match and thereby
be able to capture the respective numerical translation for the
month as represented in my table. (I had supplied $MMtable in the
mail to which you have responded.)
That is, for, say, this month, I find "Jan" in the From_ line and
therefore know that this is January. I slide "Jan across my
private conversion table to ascertain that January should be
known by the numerical equivalent "01".
Btw, yes, I realize the syntax is tricky looking when one doesn't
have it down already. That's why I supplied the entire recipe set.
For those who have trouble seeing how it works, I recommend plugging
the set into your test harness (a.k.a. sandbox) and watching it
perform. Empirical study is perhaps the best of all possible ways
to gain understanding, imnsho. Not that further questions aren't
welcome, and all. It's just that I'd hope you'd try the thing out
beforehand.
:0 E # 021211 () replace space as necessary
{ DD = 0$MATCH }
Or that.
That solves the problem of converting " 9" to "09" for the date of
the ninth of the month. Knowing the From_ line is consistent, we
had captured either one or two digits where the date would be. We now
test what we'd captured. If we find two digits, as we would for a
day such as today (the 20th of the month), we're set. If we find
only one digit, though, then we can add the leading zero. Note the
`E' flag to this recipe: it only gets invoked if the prior one
failed its condition tests.
--
"If you find a path with no obstacles, it probably does not lead to
anywhere."
Thoughts of Rev. Sunnan Kubose, from _Zen in the Markets_
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail