Re: inconsistent exit status of ((count++))

[Stefano Lattarini]

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