thanks for making this discrepant behaviour of mksh more explicit in the manpage/FAQ. I believe this is helpful (as, generally, a "(in)compatibility table" comparing all relevant shells would be...).
regarding opening bugs all over the place in (at least) 3 other shells for this issue: funny ;). I think the strongest argument against changing mksh here is maintaining upward compatibility (old scripts yield same answer with new mksh: that's upward, right?). the same of course holds for the others... I even would claim that, e.g., x+=1 in an "integer context" as a short hand for ((x+=1)) might be used rather often in bash/ksh93/zsh while it should hardly _ever_ be used on integers in mksh scripts (who wants to get the integer sequence 1, 11, 111, ... in this way, eg.?). so even if the breaking change were done, it would possibly not be causing much pain, I could imagine. so I still believe that += either should choke on integers (throw an error) or do the same as the others. getting an error would be quite OK: fixing it via ((...)) would than be trivial. _not_ getting an error but totally different result than in the other shells, _that_ is not so good in my view. but I understand you do not want this change. so that's that... ;) -- You received this bug notification because you are a member of mksh Mailing List, which is subscribed to mksh. Matching subscriptions: mkshlist-to-mksh-bugmail https://bugs.launchpad.net/bugs/1857702 Title: " +=" operator does string concatenation for integer variables Status in mksh: Fix Committed Bug description: consider typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh) but typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other shells) I believe mksh should honour the integer declaration and interpret `+=' accordingly. currently, it does not even consistently use string concatentation (since the first example does not yield `01' ...). To manage notifications about this bug go to: https://bugs.launchpad.net/mksh/+bug/1857702/+subscriptions
