On 23 April 2017 at 15:35, Andrew McGlashan via luv-main <[email protected]> wrote:
> As I understand it, bash should only ever give a return status that > indicates failure if it was not able to increment the given variable; > there is no valid reason to do otherwise. Hi One very valid reason is so that constructs like this are possible: if (( variable_or_expression )) ; then do this else do that fi while (( variable_or_expression )) ; do something done until (( variable_or_expression )) ; do something done It all works as documented in 'man bash' :) You have encounterd not so much a bug as a conflict between two incompatible features that both detect nonzero exitstatus. 'set -e' is a well intentioned feature that turns out to be incompatible with useful applications of exitstatus. 'set -e' is less useful than the above, and has other deficiencies. 'set -e' should only be used in very dumb scripts, and experts recommend is best avoided altogether. Read 'man bash' description of 'set -e' to see how fiddly it is. Effective error handling requires more effort that just lobbing 'set -e' at the top of the script and expecting everything to just work by itself. If you really must, consider using 'set -e' locally around a statement: set -e some_statement set +e But it is far preferable and not particularly difficult to do this instead: some_statement || error_handling_goes_here Don't take my word for it, read the references you've been given :) Also, if you are using two indexed arrays that share a common index, it might be worth considering using an associative array instead, if you only need a unidirectional mapping? _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
