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

[Greg Wooledge]

On Fri, Jul 30, 2010 at 07:33:00PM +0100, Andrew Benton wrote:
> On 30/07/10 19:55, Stefano Lattarini wrote:
> >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

> That makes no sense to me. Why would evaluating an expression have a 
> non-zero exit status if there was no error?

The ((...)) command is used like this:

  if ((a < b)); then
    stuff
  fi

So it returns an exit status -- true or false -- depending on whether the
arithmetic expression inside it is true or false.

The syntax and semantics of the arithmetic expression are almost identical
to what's used in C.  Any expression in there has a value.  Equations or
inequalities are special cases, but just like in C, plain ol' integers
have "true" and "false" values as well:

imadev:~$ ((42)); echo $?
0
imadev:~$ ((0)); echo $?
1

There is no real concept of an "error" in an arithmetic context.  The
exit status of an arithmetic command (either ((...)) or let) is simply
determined by the value of the expression inside it.

imadev:~$ let a=5/2; echo $?
0
imadev:~$ let a=0/2; echo $?
1

In fact, the only way you CAN generate an error in an arithmetic context
is to divide by zero:

imadev:~$ let a=2/0; echo $?
bash: let: a=2/0: division by 0 (error token is "0")
1

But that is such a rare case, and so completely preventable, that there's
just no provision to distinguish it from the case where an expression
evaluates to zero.