> From: "Matthias Andree" <matthias.and...@gmx.de> > To: 530749-d...@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 <r...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org