On Sun, Dec 12, 2004 at 10:22:32AM -0600, David W. Tamkin wrote:
Robert Allerstorfer wrote:
For example, the original Subject header may look like this:
Subject: =?utf-8?q?First-line-followed-by-one-space?=
Second-line
Please note that there is only one space character in it. When I let
procmail do
:0
* $ ^subject:[$WS]+\/.+
{
av_SUBJECT = $MATCH
}
where $WS holds the SPACE and TAB character, this results in
Assigning "av_SUBJECT==?utf-8?q?First-line-followed-by-one-space?=
Second-line"
Now the unfolded Subject got an additional space at the place the
newline was. How can I avoid replacing all these newlines by a space?
I'd say punt.
:0
* $ ^subject:[$WS]+\/.+
{
av_SUBJECT = `echo "$MATCH" | sed 's/ */ /g'`
}
[can't remember the right syntax for tr -s right now]
You're not going to be able to do it within procmail, because for
scanning the head, procmail's regexp engine treats continuation newlines
as spaces. When you extract into $MATCH, there's no way to tell those
two spaces from a real pair of adjacent spaces that were there before.
True. However, we oculd go for "damage control."
This works:
SPACE = " "
TAB = " "
WS = "$SPACE$TAB"
:0
* $ ^Subject:.*\/[^$WS].+
{ H_SUBJ = $MATCH }
:0
* $ MATCH ?? $SPACE$SPACE
{ H_SUBJ = `formail -zx Subject | tr -d '\012'` }
LOG = "$NL H_SUBJ is >$H_SUBJ< $NL"
(I stuck the log thing in to make my testing easy to see results for.)
If the situation is only important to Robert's application for
base65-encoded or quoted-printable Subject lines, then we could
further reduce the likelihood of needing the piped action in the
second recipe, with something like:
:0
* MATCH ?? ^^?utf-8[?][bq][?]
* $ MATCH ?? $SPACE$SPACE
{ H_SUBJ = `formail -zx Subject | tr -d '\012'` }
--
dman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail