quilt-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Quilt-dev] quilt mail not threading patches


From: Jean Delvare
Subject: Re: [Quilt-dev] quilt mail not threading patches
Date: Mon, 10 Apr 2017 11:37:31 +0200

Hi Okash,

Sorry for the late reply.

On Sun, 12 Mar 2017 09:28:25 +0000, Okash Khawaja wrote:
> Using quilt mail, I am able to send patchset. However, they don't appear
> threaded. Checking the headers of received emails, I couldn't find
> References header which it should be using, or In-Reply-To. Is there
> something I have missed?
> 
> Quilt version is 0.65.

Thanks for your report. I tested this morning and you are correct, the
"References:" headers are missing. I don't use the mail command much,
but I am pretty certain it used to work. I suspect it was broken by
commit 1d659bebaf3d ("quilt/mail: Remove procmail dependency") in v0.64.

Kent, your code is looking for "Message-ID:", case-sensitive, in the
introduction message. However "quilt mail" generates a "Message-Id:"
header there (notice the lower-case "d".) Apparently formail was not so
strict about case and would accept both. While RFC2822 suggests
"Message-ID:", the case itself doesn't appear to be part of the
standard, and I have seen both in practice. Actually I have even seen a
few occurrences of "Message-id:". We should support all flavors. The
only thing everybody seems to agree on is the leading capital "M".

The same problem will happen for other multi-word headers such as
"In-Reply-To:", which I have sometimes seen written "In-reply-to:".

I have created a ticket to track this bug:
https://savannah.nongnu.org/bugs/index.php?50775

One way to address the problem is to make function
"extract_header_value" ignore the case of the header field completely.
Would there be any drawback to this approach?

--- quilt.orig/quilt/mail.in    2016-11-03 09:48:37.242728725 +0100
+++ quilt/quilt/mail.in 2017-04-10 11:15:43.986717171 +0200
@@ -95,7 +95,7 @@ extract_header_value()
 
       # Long Header Fields may span multiple lines, in which case CRLF
       # is followed by space or tab (RFC 2822)
-      sed -n "/^${header}/,/^[^[:blank:]]/ { /^${header}/ { s/^${header}//p; 
n; }; /^[^[:blank:]]/q; /^$/q; p; }"
+      sed -ne "/^${header}/I,/^[^[:blank:]]/ { /^${header}/I { 
s/^${header}//I; p; n; }; /^[^[:blank:]]/q; /^$/q; p; }"
 }
 
 # See RFC 2822 Internet Message Format for how the In-Reply-To and

I know that /I is a GNU-specific modifier, but I see we are already
using it in various places in the "mail" command anyway, so a few more
occurrences shouldn't make a difference. (For completeness, the sed
manual pages of FreeBSD and NetBSD document it as supported, so while
not standard, it appears to be portable to some degree. Doesn't seem to
be supported on OpenBSD nor SunOS though...)

A more portable approach would be to explicitly spell out all the
alternatives:

--- quilt.orig/quilt/mail.in    2016-11-03 09:48:37.242728725 +0100
+++ quilt/quilt/mail.in 2017-04-10 11:07:44.603293128 +0200
@@ -105,7 +105,7 @@ in_reply_to_header()
 {
        local message=$1 message_id
 
-       message_id=$(extract_header_value Message-ID: < "$message")
+       message_id=$(extract_header_value Message-[Ii][Dd]: < "$message")
        message_id=${message_id# }
        [ -n "$message_id" ] && echo "In-Reply-To: $message_id"
 }
@@ -114,14 +114,14 @@ references_header()
 {
        local message=$1 message_id references in_reply_to
 
-       message_id=$(extract_header_value Message-ID: < "$message")
+       message_id=$(extract_header_value Message-[Ii][Dd]: < "$message")
        message_id=${message_id# }
 
        references=$(extract_header_value References: < "$message")
        references=${references# }
        if [ -z "$references" ]
        then
-               in_reply_to=$(extract_header_value In-Reply-To: < "$message")
+               in_reply_to=$(extract_header_value In-[Rr]eply-[Tt]o: < 
"$message")
                in_reply_to=${in_reply_to# }
                if [ -n "$in_reply_to" ]
                then

But that makes the code harder to read, and seems more likely to break
if other headers ever need the same, or if people become more creative
about case in the future. So I like the 1st solution better.

Kent, what do you think?

-- 
Jean Delvare
SUSE L3 Support



reply via email to

[Prev in Thread] Current Thread [Next in Thread]