On Thu, 29 Mar 2001, Jorge Godoy wrote:
--daemon with an required argument makes it impossible to request
that, by default, fetchmail should behave in daemon mode... AND to
override the poll interval at the .fetchmailrc file.
Why? I use that option and all I had to do is to pass the time
interval I want... I don't see any problem or inconvenient in doing
so.
Nor do I. But I read documentation, and so do you. We know (because the
documentation says so) that we should edit something else than the system's
fetchmailrc to change the daemon poll interval. Unfortunately, I've found
that not everyone does that :(
You said that it makes it necessary for the user to edit the file to
change the interval... Having a default value will also make it
necessary to edit the same file to change the interval if he doesn't
want it.
Read the patch. It does not. With the patches, the behaviour is as follows:
fetchmail --daemon
(no set daemon in .fetchmailrc) -> same as -d300
fetchmail --daemon=200
(overrides whatever is in .fetchmailrc) -> same as -d200
fetchmail --daemon
(set daemon 1000 in .fetchmailrc) -> same as -d1000
So, initscripts/ppp-up scripts would use --daemon without an interval.
Hmmmm... I don't see much sense about defining a poll interval in
.fetchmailrc if it will be run as a daemon. You can call it with the
interval in several places where it will be started "automatically"
(e.g. ~/.bash_login or any of the files executed automatically when
the system starts...)
I don't follow you. The problem is that if I add --daemon N to these
scripts, I get complains that "set daemon" is not working. If I do not add
--daemon N, I get complains that "fetchmail is acting funny".
I.e. it's an usability issue, not a technical one. The real issue is whether
the bad side-effect of requiring --daemon=interval instead of --daemon
interval is worth the new functionality or not.
And how would it be if he doesn't want the defaul 300s interval? He
would have to edit the same file. In what manner does it differ from
No. He could change the interval in .fetchmailrc (actually, /etc/fetchmailrc
for the "system-wide fetchmail daemon" as I called it in Debian).
I think that we should remove the daemon option from the .fetchmailrc
file... It makes more sense to me... Or make it obligatory to have the
Please don't. You will notice that in no moment did I suggest touching the
.fetchmailrc syntax or behaviour, and that's for a good reason. It would
cause trouble. Also, to change the command-line behaviour, I sent a RFC
instead of simply proposing a patch (the patch is there because I wanted to
make sure it was doable first :P )... because such changes have to be
thought of carefully.
:-) RTFM seems OK to me... ;-)
Well, I take QA a bit more seriously than that, and keeping the bug count
low helps QA and my own sanity (I've seen what dealing with stupid bug
reports too often does to people. Talk to our (Debian's) XFree86 maintainer
one day, you'll find his ideas on the subject quite interesting).
I can easily hack something that will not go against upstream fetchmail for
Debian, but that hack will most probably be a Debian-only solution (i.e: it
will not benefit non-Debian users), so it is not my first option.
Here in Brazil we have a saying that can be translated to something
like "teach him how to fish and he'll be able to feed everyday; give
him the fish and he'll eat only once".
I'm Brazilian. I'm typing this from Campinas/SP, actually. I know the
popular wisdom piece you speak of quite well, and I've said it to others
quite often :P
I think of RTFM as teaching how to fish. :-)))
Weird, most people I know here can fish, but can't read manuals (or won't
read manuals, which amounts to the same in the end) :P
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh