1) If both fetchlimit and limit are specified (say, -B 10 -l 1000),
fetchlimit sometimes returns PS_MAXFETCH instead of PS_SUCCESS, even
though there is no remaining mail. Sometimes, this also leads to an
unnecessary reconnection.
2) If the fetchmailrc file ends in a number immediately followed by
EOF, fetchmail gives a parse error.
set daemon 300<EOF>
fetchmail: parse error at 0
No error occurs if the number is followed by atleast one character
set daemon 300;<EOF>
set daemon 300 <EOF>
set daemon 300<CR><EOF>
give no errors. The problem is in the trailing context (/) used in the
lex pattern. The trailing context is unnecessary as input like "300m"
or "-100z" will anyway be treated as a string.
Here is a patch that fixes both the bugs:
============================================================================
diff -Naur fetchmail-6.2.3.orig/driver.c fetchmail-6.2.3/driver.c
--- fetchmail-6.2.3.orig/driver.c 2003-07-30 16:25:40.000000000 +0530
+++ fetchmail-6.2.3/driver.c 2003-08-05 11:34:18.000000000 +0530
@@ -704,7 +704,7 @@
}
/* perhaps this as many as we're ready to handle */
- if (maxfetch && maxfetch <= *fetches && *fetches < count)
+ if (maxfetch && maxfetch <= *fetches && num < count)
{
report(stdout, GT_("fetchlimit %d reached; %d messages left on
server %s account %s\n"),
maxfetch, count - *fetches, ctl->server.truename,
ctl->remotename);
diff -Naur fetchmail-6.2.3.orig/rcfile_l.l fetchmail-6.2.3/rcfile_l.l
--- fetchmail-6.2.3.orig/rcfile_l.l 2003-07-17 06:33:20.000000000 +0530
+++ fetchmail-6.2.3/rcfile_l.l 2003-08-04 18:00:03.000000000 +0530
@@ -199,7 +199,7 @@
(#.*)?\\?\n { prc_lineno++; } /* newline is ignored */
--?[0-9]+/[^a-zA-Z] { yylval.number = atoi(yytext); return NUMBER; }
+-?[0-9]+ { yylval.number = atoi(yytext); return NUMBER; }
[^=;:, \t\r\n]+ {
char buf[MSGBUFSIZE];
============================================================================
--
Sunil Shetye.