On 06/14/2016 12:47 AM, Eric Wong wrote:
Samuel GROOT wrote:
On 06/09/2016 02:21 AM, Eric Wong wrote:
Samuel GROOT wrote:
Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
Should we handle \n\r at end of line as well?
"\n\r" can never happen with local $/ = "\n"
If the emai
Samuel GROOT wrote:
> On 06/09/2016 02:21 AM, Eric Wong wrote:
> >Samuel GROOT wrote:
> >>Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
> >>Should we handle \n\r at end of line as well?
> >
> >"\n\r" can never happen with local $/ = "\n"
>
> If the email file contains "\n\r", s
On 06/09/2016 02:21 AM, Eric Wong wrote:
Samuel GROOT wrote:
Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
Should we handle \n\r at end of line as well?
"\n\r" can never happen with local $/ = "\n"
If the email file contains "\n\r", setting $/ = "\n" will leave "\r" at
the
On 06/09/2016 08:51 AM, Eric Sunshine wrote:
On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT
wrote:
On 06/08/2016 10:17 PM, Junio C Hamano wrote:
Eric Sunshine 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
On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT
wrote:
> On 06/08/2016 10:17 PM, Junio C Hamano wrote:
>> Eric Sunshine 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
Samuel GROOT wrote:
> Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
> Should we handle \n\r at end of line as well?
"\n\r" can never happen with local $/ = "\n"
> [1] *
> http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm
--
To unsubscribe from this li
On 06/08/2016 10:17 PM, Junio C Hamano wrote:
Eric Sunshine 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:
Samuel GROOT wrote:
> +++ b/perl/Git.pm
> +sub parse_email {
> + my %mail = ();
> + my $fh = shift;
> + my $last_header;
> +
> + # Unfold and parse multiline header fields
When you libify, I suggest you localize $/ since $/
may be set to something other than "\n" by a caller
and
Eric Sunshine 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 m
On Wed, Jun 8, 2016 at 3:30 PM, Samuel GROOT
wrote:
> On 06/08/2016 08:12 PM, Eric Sunshine wrote:
>> On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano wrote:
>>> Samuel GROOT writes:
>>> The pattern is not anchored at the right end of the string;
>>> intended? Is it worth worrying about a lone '\
On 06/08/2016 09:31 PM, Junio C Hamano wrote:
Samuel GROOT writes:
I think it's the best way to do it indeed. Furthermore, we did trim
CRs and LFs in header fields, but not in the message, making the
subroutine inconsistent.
Should we rename the subroutine to `parse_header` or leave it as it
On 06/08/2016 07:58 PM, Junio C Hamano wrote:
Samuel GROOT writes:
+sub parse_email {
+ my %mail = ();
+ my $fh = shift;
+ my $last_header;
+ # Unfold and parse multiline header fields
+ while (<$fh>) {
+ last if /^\s*$/;
You stop at the end of f
Samuel GROOT writes:
> I think it's the best way to do it indeed. Furthermore, we did trim
> CRs and LFs in header fields, but not in the message, making the
> subroutine inconsistent.
>
> Should we rename the subroutine to `parse_header` or leave it as it is?
If it lives inside git-send-email,
On 06/08/2016 08:12 PM, Eric Sunshine wrote:
On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano wrote:
Samuel GROOT writes:
+sub parse_email {
+ my %mail = ();
+ my $fh = shift;
+ my $last_header;
+ # Unfold and parse multiline header fields
+ while (<$fh>) {
+
On 06/08/2016 08:32 PM, Junio C Hamano wrote:
Eric Sunshine writes:
+ # Separate body from header
+ $mail{"body"} = [(<$fh>)];
+
+ return \%mail;
The name of the local thing is not observable from the caller, but
because this is "parse-email-header" and returns "header fields"
wit
Eric Sunshine writes:
>>> + # Separate body from header
>>> + $mail{"body"} = [(<$fh>)];
>>> +
>>> + return \%mail;
>>
>> The name of the local thing is not observable from the caller, but
>> because this is "parse-email-header" and returns "header fields"
>> without reading the "mail
On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano wrote:
> Samuel GROOT writes:
>> +sub parse_email {
>> + my %mail = ();
>> + my $fh = shift;
>> + my $last_header;
>
>> + # Unfold and parse multiline header fields
>> + while (<$fh>) {
>> + last if /^\s*$/;
>
> You st
Samuel GROOT writes:
> +sub parse_email {
> + my %mail = ();
> + my $fh = shift;
> + my $last_header;
> + # Unfold and parse multiline header fields
> + while (<$fh>) {
> + last if /^\s*$/;
You stop at the end of fields before the message body starts.
> +
We need a simple and generic way to parse an email file.
Since it would be hard to include and maintain an external library,
create an simple email parser subroutine to parse an email file.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
We chose to crea
19 matches
Mail list logo
