🚀 go-pugleaf

In article <3910@taux01.UUCP> crehta@taux01.nsc.com (Ran Ever-Hadani) writes:
} In article <9558@ogicse.ogi.edu> schaefer@ogicse.ogi.edu (Barton E. Schaefer) writes:
} >In article <3906@taux01.UUCP> crehta@taux01.nsc.com (Ran Ever-Hadani) writes:
} >} What I get is a message with two From: headers -
} >} first the additional one I don't want, and then the original I do
} >} want.
} 
} >             There isn't any way to get mush to reorder the headers,
} >so hdr_format strings %a and %n are always going to use the first one,
} >but you will get the second From: included when you "replyall".
} 
} I don't see the sense in that; even good old ucb mail knows to
} consider the last one.

How so?  I've just tried /usr/ucb/mail under DYNIX (== 4.2 BSD), Mt. Xinu
4.3 BSD, and SunOS 4.0.3.  None of them sees a second From: header, even
to include it in replyall.  (I note that Sun's ucbMail seems to have picked
up a few mush features lacking in the others, though. :-)

} Is there any reason not to change mush so that it will always
} use the last one rather than the first?  This makes more sense,
} as added headers are usually prepended to the existing ones.

There are several things going on here.  The first is that mush gathers
all the headers having the same name into a single string when it does
any operation that extracts headers having that name.  This allows you,
for example, to use multiple To: lines when addressing your mail,
without worrying about the syntax for multi-line headers or fearing that
some of your intended recipients might be missed.  The string is built
up in the order the headers are scanned, because that's the simplest and
most obvious way to handle it; the standards do not specify a semantics
for duplicated headers.  The second thing going on is that once the
entire string has been extracted, mush pulls the first name/address pair
for use in %a and %n expansions.  Again, this is quick and easy, and
usually correct.

So, is there any reason not to change it?  Only that it would require
either (1) extra work for certain special-case headers in the header
display code or (2) a significant change to general header scanning
code.  A better question is, is there any reason *to* change it?  My
personal feeling is that (with the obvious exception of your problem) 
the more recently added header would be the one you'd *want* to get.
Any one else (or even Ran) want to make a more convincing case for
making such a change?  Or at least hazard an opinion?
-- 
Bart Schaefer						schaefer@cse.ogi.edu