[pkg-fetchmail-maint] Bug#530749: 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)

[Matthias Andree]

Am 30.05.2009, 00:23 Uhr, schrieb Reuben Thomas <rrt at sc3d.org>:

> 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:

Well... it's indeed suboptimal, but there's also shortcutting.

I. e. if fetchmail returns 0, the || part isn't executed, so the status  
remains 0 and exit 0 triggers (arguably superfluous).

If fetchmail returns 1, the || part is executed, $? is 1, so [ $? -eq 1 ]  
exits with 0 status, and exit 0 triggers (again, superfluous).

If fetchmail returns anything else, the || part is execute, $? isn't 1, so  
[ $? -eq 1 ] exits with nonzero status, and exit 0 is skipped. (again,  
superfluous).

Try something like:

( ( exit 3 ) || [ $? -eq 1 ] && exit 0 ) ; echo $?

Where the first ( exit 3 ) uses the exit code that fetchmail would use.

I get "0" printed if I put ( exit 0 ) and ( exit 1 ) - success and NOMAIL  
- there, and I get "1" if I put ( exit 2 ) and ( exit 3 ) there.


You can indeed safely omit the "&& exit 0" part (it will only ever execute  
if the exit status is 0 anyways).

What are we missing here?

> 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.)

You could also argue that "no mail" is only an error in check mode. I  
think user requirements will differ, but I'd like to avoid option  
proliferation -- there's a nontrivial amount of code involved in adding an  
option; orders of magnitude more than what users need in shells.

> 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.

I don't see why my approach is wrong (except for the unneeded && exit 0),  
as argued above.
If the Almqvist shell goofs up (it at least used to have POSIX  
non-compliance bugs around || and &&), I suggest to fix the shell.

Otherwise this appears to be the same argument as 0 sans the "stupid"  
part. If users need to map multiple status codes to 0, they can use '||  
case $? in...1|2|3)...;; *)...;; esac'    instead of '|| [ $? -eq 1 ]'

> 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?

Yes, will do. (It's in TODO.txt for 6.3.10.)

> 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?

Yes, an option is always worthwhile, but the effort is way out of balance.  
It's a dozen characters in the shell, but documentation and adding the  
option to command line and rcfile parser and manual page is a multiple of  
that. I'm not going to do it.

-- 
Matthias Andree