At Friday 30 July 2010, Andrew Benton wrote:
> On 30/07/10 19:55, Stefano Lattarini wrote:
> > At Thursday 29 July 2010, Andrew Benton wrote:
> >> andy:~$ count=0
> >> andy:~$ ((count++))
> >> andy:~$ echo $?
> >> 1
> >> andy:~$ ((count++))
> >> andy:~$ echo $?
> >> 0
> >
> > I don't think it's a bug, it's just an effect of:
> > 1. `((EXPR))' returning a non-zero exit status iff EXPR
> > evaluates to zero, and
BTW, this behaviour is documented here, in the entry `((...))':
<http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs>
> That makes no sense to me. Why would evaluating an expression have
> a non-zero exit status if there was no error?
It can be very useful for use in conditional or looping constructs, e.g.:
if ((verbosity > 1)); then
echo "blah blah..."
fi
Also, non-zero exit status does not necessary indicate a true error in
the Unix world (the `grep' utility is a noteworthy and outstanding
example).
> That makes the exit status no use at all for evaluating whether an
> error has occurred.
> How can I check for errors if I can't rely on the exit status? How
> can that not be a bug?
>
It's somewhat of a trade-off; and I hope that my explanation makes it
clear that it's a good tradeoff.
But then, maybe an exit status of `2' instead of `1' in case of errors
in ((...)) would be helpful -- currently the exit status is still `1'
also if a real error is present:
$ ((1+)); echo \$?=$?
bash: ((: 1+: syntax error: operand expected (error token is "+")
$?=1
Regards,
Stefano
