Am 30.05.2009, 00:23 Uhr, schrieb Reuben Thomas <r...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
