procmail
[Top] [All Lists]

Re: formail -I misunderstanding

1999-01-14 09:04:56
Jim Osborn <jimo(_at_)eskimo(_dot_)com> writes:
I'm using the recipe below to sort the headers of list mail
into predictable order, but when the incoming mail has one
of the elements missing, formail adds an empty one.  The
formail man page says something like: "-I ...If headerfield
consists of only a field name, it effectively deletes the field."

So I'm puzzled; I'd think when it gets:

  `formail ...-I "Reply-to: "...'

that it would ignore it, but obviously, I'm wrong.  Is it the
trailing space?  Anyone have an elegant solution?

Yes, it is the trailing space.  The _easiest_ solution that I can think
of is to feed the message through another invocation of formail with
the -z flag.  The sneakiest is to the ${var+blah} form of variable
interpolation to avoid passing the entire -I argument to formail.

Solution 1:
        :0 fwh
        | formail       -I"From: $FROM" \
                        -I"Reply-to: $RT" \
                        -I"X-Mailer: $XM" \
                        -I"Message-Id: $MID" \
                        -I"Date: $DATE" \
                        -I"To: $TT" \
                        -I"Cc: $CC" \
                        -I"Subject: $SUBJ" \
        | formail -z

Solution 2:
        :0 fwh
        | formail       ${FROM:+-I"From: $FROM"} \
                        ${RT:+-I"Reply-to: $RT"} \
                        ${XM:+-I"X-Mailer: $XM"} \
                        ${MID:+-I"Message-Id: $MID"} \
                        ${DATE:+-I"Date: $DATE"} \
                        ${TT:+-I"To: $TT"} \
                        ${CC:+-I"Cc: $CC"} \
                        ${SUBJ:+-I"Subject: $SUBJ"}

Note 1: It is considered wise to put a space before the backslash that
continues the line to avoid problems with arguments being joined.  It
also makes it easier to read.

Note 2: I've eliminated the space between the -I and its argument in
the above.  This is a matter of taste in solution 1 (I probably
_wouldn't_ do it there if this was in my rcfile), but it's necessary in
solution 2 as the shell may or may not allow unquoted spaces in the
second part of the ${variable:+blah}.  For example, under solaris 2.6,
/bin/sh barfs on ${FROM:+-I "From: $FROM"}, while /bin/ksh handles it
just fine.  I think the POSIX shell standard requires that it be
allowed, but, well, will your _next_ system be POSIX compliant?

Note 3: You put all the assignments to FROM, RT, XM, etc in a nested
block.  A nested block that has neither flags nor conditions is
pointless: variables are not local to nested blocks.


Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>