On Tue, 18 Sep 2001, Eric S. Raymond wrote:
1. I cannot explain this. Might stripcr get lost over the daemon-wait
time interval, I did not wait until that expired?
It doesn't seem likely. Just looking at this grep log,
grep -n -e stripcr *.[ch] /dev/null
conf.c:349: booldump("stripcr", ctl->stripcr);
fetchmail.c:835: FLAG_MERGE(stripcr);
fetchmail.c:1035: DEFAULT(ctl->stripcr, (ctl->mda != (char *)NULL));
fetchmail.c:1621: printf(_(" Carriage-return stripping is %s
(stripcr %s).\n"),
fetchmail.c:1622: ctl->stripcr ? _("enabled") : _("disabled"),
fetchmail.c:1623: ctl->stripcr ? "on" : "off");
fetchmail.h:275: flag stripcr; /* if TRUE, strip CRs in text */
rcfile_y.c:1423:{current.stripcr = FLAG_TRUE;;
rcfile_y.c:1495:{current.stripcr = FLAG_FALSE;;
sink.c:240: if (ctl->stripcr)
it seems pretty cleat that stripcr can only be set at profile-parse time.
Have you considered setting a watchpoint on stripcr? GDB might be able
to tell you where it's changing.
I will re-test. However, I need to make sure nothing of this mail enters
my Gnus which gets confused on CR. Is there a reliable way to prevent
fetchmail from falling back to procmail? Would configuring "/bin/false"
or "no" as fallback MDA do this job?