[pkg-fetchmail-maint] Bug#530749: closed by "Matthias Andree" <matthias.andree at gmx.de> (Re: Bug#530749: fetchmail: Please add option to make "no mail" not an error condition)

[Reuben Thomas]

> From: "Matthias Andree" <matthias.andree at gmx.de>
> To: 530749-done at bugs.debian.org
> Date: Thu, 28 May 2009 16:47:09 +0200
> Subject: Re: [pkg-fetchmail-maint] Bug#530749: fetchmail: Please add option to make "no mail" not an error condition
> Am 27.05.2009, 15:12 Uhr, schrieb Reuben Thomas <rrt at sc3d.org>:
> the remaining motivation for a feature request is based on
> arbitrary and false claims.
>
> The "no mail" exit code is separate and something like
>
>        fetchmail --foo blah.example.org || [ $? -eq 1 ] && exit 0

Well done for thinking of this, but it does not have the desired
effect. || and && have equal precedence and are left-associative
(according to sh(1posix)), so the above is the same as

( fetchmail --foo blah.example.org || [ $? - eq 1 ] ) && exit 0

i.e. it always ends up returning 0. So, with some brackets it can be fixed:

fetchmail --foo blah.example.org || ( [ $? - eq 1 ] && exit 0 )

I also had to check that the use of [...] was POSIX. It is, so that's fine.

I suggest that there are four obvious points of view here:

0. This is a stupid way to want to run fetchmail. "No mail" is an
error condition. (I take the opposite view: I think "No mail" should
not be an error condition, but it's too late to fix it in fetchmail.)

1. Despite the fact that I didn't guess this short command (I ended up
writing a wrapper), and that you didn't get it right, users can work
it out for themselves, or can write a wrapper script. I suggest again
that this is false: while maybe in my case I should be running
fetchmail in daemon mode (as I said, that's something I've not got to
work reliably, and as you rightly observed, we should discuss one bug
at a time in the BTS), there are other reasons why one might want to
call fetchmail from a script and consider that "no mail" is not an
error condition.

2. It's a reasonable thing to want to do, but not common enough to
warrant a command-line switch. In that case, a FAQ entry might be
appropriate?

3. It warrants a command-line switch.

Personally, although I think 3 is worthwhile (because it is a fix for
what I consider a design bug), 2 would be almost as good, and perhaps
the corrected version of the above would make a good example for the
FAQ or even the man page?

-- 
http://rrt.sc3d.org
humour, n. unexpected recognition