On 06/09/2016 08:51 AM, Eric Sunshine wrote:
On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT
<samuel.groot@xxxxxxxxxxxxxxxx> wrote:
On 06/08/2016 10:17 PM, Junio C Hamano wrote:
Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
An embedded CR probably shouldn't happen, but I'm not convinced that
folding it out is a good idea. I would think that you'd want to
preserve the header's value verbatim. If anything, I'd expect to see
the regex tightened to:
s/\r?\n$//;
Yes, that would be more sensible than silently removing \r in the
middle which _is_ a sign of something funny going on.
s/\r?\n$// looks fine.
Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
[1] * http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm
You could certainly use s/\x0d?\x0a$// rather than s/\r?\n$// to be
really robust, but I doubt it matters much today. The reason for using
hex codes is that \r and \n will resolve to CR and LF in the local
character encoding, and those may not be 0x0d and 0x0a, respectively.
I believe the canonical example given in the Camel book was EBCIDIC in
which \r is 0x0d, but \n is 0x25, not 0x0a as it is in ASCII.
My question was more about the `\n\r` case handled by Email::Simple,
does it make sense to handle it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html