Dear Chet Many thanks for your impressively swift response. It is enlightening to see how these expressions are parsed.
For the record, whilst I can now see how they are parsed, it feels particularly unsatisfactory that the following two expressions yield the same result when the variable i happens to have unwittingly been decremented below zero (by bash arithmetic evaluation by the way - not by the output of some external command): echo $((3-10#${i})) echo $((3+10#${i})) As you indicate, this is caused by 10# being parsed as zero. That silent assumption of zero effectively then also silently nullifies/swallows the preceding operator. Ilkka Virta's email helpfully pointed me to a somewhat related debate that occurred about 11 months ago. I agree with your comment in this debate: "There would be a good case for rejecting the '10#' because it's missing the value." It is this silently proceeding with a plausible (but undesirable) output in such cases which is especially concerning. In the meantime it would seem cautionary to advise against the pitfall of using base# prefixed to variables (contrary to mywiki.wooledge.org/ArithmeticExpression) unless you can be confident that they will never be decremented below zero. At the very least it would be helpful if the manual reflected that 10# followed by anything other than a digit ([0-9a-zA-Z@_]) is parsed as zero, and rlarified more completely the constraints of "number" for "n" in the "base#" paragraph. I cannot find anywhere else in the manual where the word "number", "numeric value" or "integer" excludes values less than zero without explicitly stating so. On the other hand phrases like "[if] ... number/numeric values less than zero", "if ... [not] a number greater than [or equal to] zero" are used repeatedly. In those cases "number" clearly doesn't exclude those less than zero. Jeremy Townshend