
On 23/04/17 10:32, David via luv-main wrote:
On 23 April 2017 at 03:59, Andrew McGlashan via luv-main <luv-main@luv.asn.au> wrote:
The return code from ((i++)) operation is different when i has an initial value of 0.
Well, that is by consistent design, so I wouldn't consider that a bug, myself.
Bash provides pre- and post- increment and decrement operators, and you seem to have chosen the wrong one.
$ i=0; ((i++)); echo $? 1 $ i=0; ((++i)); echo $? 0
Search 'man bash' for the string "pre-increment".
Pre or post makes no real difference. The problem is that "expression", in this case "i" ... causes the return value and not the operation of incrementing the expression. Using ((--i)) gives the problem when i was 1 before the increment and using ((i++)) gives the problem when i was 0 before the increment. Anyway, I got the following response to my report via bashbu, to which I still think is questionable. <quote> On Sat, Apr 22, 2017 at 12:49 PM, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote: [...]
The return code from ((i++)) operation is different when i has an initial value of 0.
This is not a bug. Please read the Bash reference manual section on conditional constructs: https://www.gnu.org/software/bash/manual/bash.html#index-commands_002c-condi... | 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" This is also described in other sources: 1. http://wiki.bash-hackers.org/commands/builtin/let#description 2. http://mywiki.wooledge.org/ArithmeticExpression#Arithmetic_Commands Also see the 1st example in http://mywiki.wooledge.org/BashFAQ/105 ("Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected?"), which mentions this pitfall. You can also find extensive discussions in the bug-bash archives on why you shouldn't be using set -e, regardless of how many "sources" on the web claim that it helps write "robust" or "correct" shell scripts. </quote> Kind Regards AndrewM