On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT <samuel.gr...@grenoble-inp.org> wrote: > On 06/08/2016 10:17 PM, Junio C Hamano wrote: >> Eric Sunshine <sunsh...@sunshineco.com> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
