On 23.04.17 13:17, Andrew McGlashan via luv-main wrote: > Anyway, I got the following response to my report via bashbu, to which I > still think is questionable. > > <quote> ... > | The arithmetic expression is evaluated according to the rules > described below (see Shell Arithmetic). If the value of the expression > is non-zero, the return status is 0; otherwise the return status is 1. > This is exactly equivalent to > | > | let "expression"
Andrew, that makes crystal clear that the only problem is a failure to read the manual before forming a firm opinion. Interpreting a documented feature as a "problem" isn't entirely useful. ;-) ISTM that the feature usefully returns two values simultaneously; the incremented variable, and zero detection. That could be used for exiting a simple loop, detecting convergence of an iterative function, etc. Given that any modulo 2^n binary counter can increment/decrement infinitely, merely overflowing/underflowing at 0, it can never ever "fail to increment/decrement", if implemented as a simple CPU ALU operation, or multiple thereof. The documented feature is a simple way to communicate that overflow/underflow. That's useful. ISTM, then, that it is the use of "set -e" which is the problem. It is not documented to detect errors, but merely "exits with a non-zero status". If it is needed elsewhere in the script, have you considered setting it later, or using an unset/set around the arithmetic? Erik _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
