14 messages in net.sourceforge.lists.courier-maildropRe: [maildropl] Re: Line endings / DO...
FromSent OnAttachments
Henk van LingenOct 5, 2005 7:05 am 
Jay LeeOct 5, 2005 7:24 am 
Tony EarnshawOct 5, 2005 8:50 am 
Tom DiehlOct 5, 2005 11:40 am 
Henk van LingenOct 5, 2005 2:58 pm 
Paul L. AllenOct 5, 2005 7:32 pm 
Henk van LingenOct 6, 2005 7:31 am 
Paul L. AllenOct 6, 2005 7:48 am 
Jay LeeOct 6, 2005 8:05 am 
Jay LeeOct 6, 2005 8:35 am 
Paul L. AllenOct 6, 2005 9:02 am 
moussOct 6, 2005 10:34 am 
Thorsten HaudeOct 6, 2005 12:33 pm 
Sam VarshavchikOct 6, 2005 3:31 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [maildropl] Re: Line endings / DOS formatActions...
From:Henk van Lingen (hen@cs.uu.nl)
Date:Oct 6, 2005 7:31:47 am
List:net.sourceforge.lists.courier-maildrop

On Thu, Oct 06, 2005 at 03:31:00AM +0100, Paul L. Allen wrote: > > >However these days OP has users who are too stupid to edit a file in a > >unix terminal,

...

> Really, really, really, really. If you understand regexps then you ought > to understand EOL conventions.

This may all be true, but it's besides my point that maildrop shouldn't fail on a silly DOS format.

Anyways: I've made a patch which I think works. It produces the same lexer output in verbose > 8 mode when runned on a unix and on a dos filterfile. For those interested:

drempt:/users/henkvl 584% diff -c /private/maildrop-1.8.0/maildrop/lexer.C /projects/pkg/rpm/el3/BUILD/maildrop-1.8.0/maildrop/lexer.C *** /private/maildrop-1.8.0/maildrop/lexer.C 2005-10-06 16:12:02.000000000 +0200 --- /projects/pkg/rpm/el3/BUILD/maildrop-1.8.0/maildrop/lexer.C 2004-01-15 04:12:13.000000000 +0100 *************** *** 85,93 **** while ((c=curchar()) >= 0 && isspace(c)) { nextchar(); ! if (c == '\r') ! continue; ! if (c == '\n') // Treat as semicolon { t.Type(Token::semicolon); return; --- 85,91 ---- while ((c=curchar()) >= 0 && isspace(c)) { nextchar(); ! if (c == '\n' || c == '\r') // Treat as semicolon { t.Type(Token::semicolon); return;

Summary: '\r' shouldn't be treaded as an extra semicolon but should be ignored.

Cheers,