Re: increment & decrement error when variable is 0
On Tue, Nov 24, 2020 at 12:07 AM Jetzer, Bill
wrote:
> ((--x)) || echo "err code $? on --x going
> from $i to $x";
>
> err code 1 on ++x going from -1 to 0
>
That's not about --x, but of the ((...)) construct:
"" (( expression ))
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" See Bash Builtins, for a full description of
the let builtin.""
https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html#Conditional-Constructs
Note the second sentence and try e.g.:
$ if (( 100-100 )); then echo true; else echo false; fi
false
That also matches how truth values work in e.g. C, where you could write if
(foo) { ... } to test if foo is nonzero.
Also, consider the return values of the comparison operators. The behaviour
here makes it possible to implement
them by just returning a number, instead of having to deal with a distinct
boolean type that would affect the exit status:
$ (( a = 0 < 1 )); echo $a
1
> err code 1 on x++ going from 0 to 1
As to why you get this here, when going to one instead of zero, remember
the post-increment returns the original value.
Variables declared in arithmetic expressions have no i flag
Should variables automatically created within arithmetic constructs have the integer flag implied? unset x; ((x = 42)); typeset -p x > declare -- x="42" Should it be: declare -i x="42" Here are cases where that would make a difference: unset x; ((x = 42)); x+=624; typeset -p x > declare -- x="42624" unset x; declare -i x; ((x = 42)); x+=624; typeset -p x > declare -i x="666" -- Léa Gris
Re: Variables declared in arithmetic expressions have no i flag
On Tue, Nov 24, 2020 at 02:30:36PM +0100, Léa Gris wrote: > Should variables automatically created within arithmetic constructs have the > integer flag implied? No. Please, no. It's bad enough that the -i flag exists in the first place, without it being randomly added to poor innocent variables. "Why did my code fail?" "Bash 5.69 added a feature that puts -i on your variables sometimes, if your first assignment to one just happens to occur inside an arithmetic context. And look here, you reused 'i' as both a numeric counter and a for loop iterator, but it just so happens the numeric counter usage occurred first, so you got slapped with the -i flag, and then your for loop iterator blew up." "OK, then why did this other script fail?" "You assumed that 'n' would get the integer flag automatically since you first assigned to it in a math command. But someone exported it as an environment variable before running your script, so it was already a string variable at the time. So you didn't get the -i flag on it." "AARGH!"
RE: increment & decrement error when variable is 0
Thank you for the clarification. I understand now.
--bill
From: Ilkka Virta
Sent: Tuesday, November 24, 2020 2:08 AM
To: Jetzer, Bill
Cc: bug-bash@gnu.org
Subject: Re: increment & decrement error when variable is 0
On Tue, Nov 24, 2020 at 12:07 AM Jetzer, Bill
mailto:jetz...@svaconsulting.com>> wrote:
((--x)) || echo "err code $? on --x going from
$i to $x";
err code 1 on ++x going from -1 to 0
That's not about --x, but of the ((...)) construct:
"" (( expression ))
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" See Bash Builtins, for a full description of the let builtin.""
https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html#Conditional-Constructs
Note the second sentence and try e.g.:
$ if (( 100-100 )); then echo true; else echo false; fi
false
That also matches how truth values work in e.g. C, where you could write if
(foo) { ... } to test if foo is nonzero.
Also, consider the return values of the comparison operators. The behaviour
here makes it possible to implement
them by just returning a number, instead of having to deal with a distinct
boolean type that would affect the exit status:
$ (( a = 0 < 1 )); echo $a
1
> err code 1 on x++ going from 0 to 1
As to why you get this here, when going to one instead of zero, remember the
post-increment returns the original value.
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
CONFIDENTIAL : This transmission may contain information that is privileged,
confidential and/or exempt from disclosure under applicable law. If you are not
the intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon)is strictly prohibited. If you received this transmission in
error, please immediately contact the sender and destroy the material in its
entirety, whether in electronic or hard copy format.
How is it explained about the `local` is valid variable
Can we validly write a line unset local a b c d e f g h i to mean: local a b c d e f g h i;unset a b c d e f g h i if yes, how come local=9 is valid variable 'local' normally ? thanks much
Re: How is it explained about the `local` is valid variable
> On Nov 24, 2020, at 8:06 PM, Budi wrote: > > Can we validly write a line > > unset local a b c d e f g h i > > to mean: local a b c d e f g h i;unset a b c d e f g h i No. Have you looked at the documentation for "unset"? vq P.S. Again, not a bug. Not appropriate for bug-bash.
