Question: All lines in my AppStats look like this: `real=19ms cpu=0ms api=0ms overhead=0ms`, it has the correct real time, but the other values are always 0. Anyone have this problem before or know how to fix this?

Answer: 
It's a convention, but a particularly useful one when you think about it. In general, if a program succeeds that's all you need to know. If it fails, however, you might need to know all kinds of information about the failure - why it happened, how to fix it, etc. Having zero mean 'success' and non-zero mean failure lets you can check pretty easily for success, and investigate the particular error for more details if you want to. A lot of APIs and frameworks have a similar convention - functions that succeed return 0 and and those that fail give back an error code describing the particular failure case.
**There are two related issues here.**

First, the OP's question, *Why 0 is true but false is 1 in the shell?* and the second, *why do applications return 0 for success and non-zero for failure?* 

To answer the OP's question we need to understand the second question. The numerous answers to this post have described that this is a convention and have listed some of the niceties this convention affords. Some of these niceties are summarized below.

**Why do applications return 0 for success and non-zero for failure?**

Code that invokes an operation needs to know two things about the exit status of the operation. *Did the operation exit successfully?* [\*1] And if the operation does not exit successfully *why did the operation exit unsuccessfully?* Any value could be used to denote success. But 0 is more convenient than any other number because it is portable between platforms. Summarizing xibo's answer to this [question](https://forums.freebsd.org/viewtopic.php?&t=25719) on 16 Aug 2011:

> 
> Zero is encoding-independent. 
> 
> 
> If we wanted to store one(1) in a 32-bit integer word, the first question would be "big-endian word or little-endian word?", followed by "how long are the bytes composing a little-endian word?", while zero will always look the same.
> 
> 
> Also it needs to be expected that some people cast errno to char or short at some point, or even to float. (int)((char)ENOLCK) is not ENOLCK when char is not at least 8-bit long (7-bit ASCII char machines are supported by UNIX), while (int)((char)0) is 0 independent of the architectural details of char.
> 
> 
> 

Once it is determined that 0 will be the return value for success, then it makes sense to use any non-zero value for failure. This allows many [exit codes](http://www.gnu.org/software/libc/manual/html_node/Exit-Status.html) to answer the question why the operation failed.

**Why 0 is true but false is 1 in the shell?**

One of the fundamental usages of shells is to automate processes by scripting them. Usually this means invoking an operation and then doing something else conditionally based on the exit status of the operation. [Philippe A.](https://stackoverflow.com/users/393262/philippe-a) explained nicely in his answer to this post that 

> 
> In bash and in unix shells in general, return values are not boolean.
>  They are integer exit codes.
> 
> 
> 

It's necessary then to interpret the exit status of these operations as a boolean value. It makes sense to map a successful (`0`) exit status to true and any non-zero/failure exit status to false. Doing this allows conditional execution of chained shell commands.

Here is an example `mkdir deleteme && cd $_ && pwd`. Because the shell interprets 0 as true this command conveniently works as expected. If the shell were to interpret 0 as false then you'd have to invert the interpreted exit status for each operation.

In short, it would be nonsensical for the shell to interpret 0 as false given the convention that applications return 0 for a successful exit status.

---

[\*1]: Yes, many times operations need to return more than just a simple success message but that is beyond the scope of this thread.

See also [Appendix E](http://tldp.org/LDP/abs/html/exitcodes.html#EXITCODESREF) in the Advanced Bash-Scripting Guide