Errors are ignored with local variable assignment
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux pingu 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2
(2022-12-13) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 4
Release Status: release
Description:
Errors are ignored when a command with error is assigned to a
local variable on the same line of declaration.
Repeat-By:
f(){
return 1
}
g(){
local v=`f`
}
h(){
v=`f`
}
i(){
local v
v=`f`
}
f && echo f
g && echo g
h && echo h
i && echo i
-
the output is 'g', but I believe there should be no output
Re: Errors are ignored with local variable assignment
On Wed, Jan 04, 2023 at 12:21:27AM -0600, Carlos Prieto López wrote:
> Description:
> Errors are ignored when a command with error is assigned to a local
> variable on the same line of declaration.
>
> f(){
> return 1
> }
>
> g(){
> local v=`f`
> }
> g && echo g
> the output is 'g', but I believe there should be no output
The "local" command has its own exit status, and this masks the exit
status of the command substitution.
You've already found a workaround:
> i(){
> local v
> v=`f`
> }
Just continue using that. This isn't a bug in bash, and it won't be
changed.
(While you're at it, you might want to switch from the obsolete backtick
syntax to the preferred $() syntax for command substitutions.)
Re: Arithmetic expression: evaluation order bug
On 12/29/22 12:23 PM, Steffen Nurpmeso wrote: Hello. Name: bash Path: /usr/ports/core Version: 5.2.15 Release: 1 > $ i=10 j=20;echo $(( i += j += i += j ));echo $i,$j 60 60,50 This has already been beaten pretty much to death, so I'll just explain how the bash expression evaluator works on this. It's all operator precedence and associativity. += has lower precedence than other operators and associates right-to-left. So var += expr looks up `var' and retrieves its value, evaluates `expr', performs the operation, and returns the value of `var' after the assignment. That means this will parse like i += (j += i += j) i += (j += (i += j)) i += (j += (i += (j))) and evaluate like j -> 20 i += 20 -> i = 30 (intermediate result) j += 30 -> j = 50 i += 50 -> i = 60 (uses initial value of i) because you evaluate by fetching the value of the lhs first, saving it and its value because you know you need it, evaluating the rhs, then performing the operation on the saved value and assigning the result. In the end, though, this is completely undefined behavior. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Arithmetic expression: evaluation order bug
On 12/30/22 3:44 PM, Steffen Nurpmeso wrote: Digital, logical, liberal, yuck :) We channeling Supertramp here? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Arithmetic expression: evaluation order bug
On 12/30/22 4:23 AM, Robert Elz wrote: For what it is worth, I tested a bunch of shells with the original expressions, all ksh variants, bosh, and bash evaluate the original expressions the bash way, all ash variants, plus yash and zsh implement it the dash way. Neither is incorrect. It really comes down to when you fetch the value on the lhs. Do you save the variable name and fetch its value after you evaluate the rhs, or do you get the lhs value at the same time you save the name? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Errors are ignored with local variable assignment
On 1/4/23 1:21 AM, Carlos Prieto López wrote: Bash Version: 5.1 Patch Level: 4 Release Status: release Description: Errors are ignored when a command with error is assigned to a local variable on the same line of declaration. This comes up often; just last month, in fact: https://lists.gnu.org/archive/html/bug-bash/2022-12/msg3.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Arithmetic expression: evaluation order bug
At 2023-01-04T10:22:15-0500, Chet Ramey wrote: > On 12/30/22 3:44 PM, Steffen Nurpmeso wrote: > > > Digital, logical, liberal, yuck :) > > We channeling Supertramp here? 🤣 Some listen to the birds in the trees singing so happily... ..and some spend their years watching the moon bear wank himself off. Regards, Branden signature.asc Description: PGP signature
Re: Arithmetic expression: evaluation order bug
On 1/4/23 10:36 AM, G. Branden Robinson wrote: ..and some spend their years watching the moon bear wank himself off. Or, if you were in Yorkshire last week, a walrus. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
unset does not remove functions like a[b] unless -f is specified
The unset builtin, when invoked without an option, should first try to
unset the variable (or array element) specified by its arguments, and
then fall back to trying to remove the function definition for the
function that has the name specified by the argument if it exists.
bash-5.1$ declare -f a; declare -p a
bash: declare: a: not found
bash-5.1$ a=hi; declare -f a; declare -p a
declare -- a="hi"
bash-5.1$ unset a; declare -f a; declare -p a
bash: declare: a: not found
bash-5.1$ declare -f a; declare -p a
bash: declare: a: not found
bash-5.1$ a () { echo ;}; a=hi; declare -f a; declare -p a
a ()
{
echo
}
declare -- a="hi"
bash-5.1$ unset a; declare -f a; declare -p a
bash: declare: a: not found
a ()
{
echo
}
bash-5.1$ declare -f a; declare -p a
bash: declare: a: not found
bash-5.1$ a () { echo ;}; declare -f a; declare -p a
a ()
{
echo
}
bash: declare: a: not found
bash-5.1$ unset a; declare -f a; declare -p a
bash: declare: a: not found
The -v option can be used to tell the unset builtin to only unset
variables (and array elements), and not fall back to removing function
definitions.
The -f option can be used to tell the unset builtin to only remove
function definitions directly.
It seems that, if an operand of unset is in the form of
validvariablename[something], the unset builtin invoked without options,
will only attempt to delete an array element specified by that argument,
and will not fall back to removing a function named like the argument
(as if the -v option was passed only for that argument).
You must specify the -f option to delete a function with a name in
that form.
bash-5.1$ a=([1]=2 3 4); a[] () { echo ;}; a[0] () { : ;}
bash-5.1$ declare -p a; declare -f 'a[]' 'a[0]'
declare -a a=([1]="2" [2]="3" [3]="4")
a[] ()
{
echo
}
a[0] ()
{
:
}
bash-5.1$ unset 'a[]' 'a[0]' 'a[1]'
bash-5.1$ declare -p a; declare -f 'a[]' 'a[0]'
declare -a a=([2]="3" [3]="4")
a[0] ()
{
:
}
bash-5.1$ unset -f 'a[0]'
bash-5.1$ declare -p a; declare -f 'a[]' 'a[0]'
declare -a a=([2]="3" [3]="4")
Same result if the `a' variable does not exist.
bash-5.1$ a[0] () { echo;}
bash-5.1$ declare -p a; declare -f 'a[0]'
bash: declare: a: not found
a[0] ()
{
echo
}
bash-5.1$ unset 'a[0]'
bash-5.1$ declare -p a; declare -f 'a[0]'
bash: declare: a: not found
a[0] ()
{
echo
}
bash-5.1$ unset -f 'a[0]'
bash: declare: a: not found
I think that this is a bug, and that bash's unset builtin should fall
back to trying to remove the function named "a[0]" in those cases.
Cheers.
emanuele6
Re: Arithmetic expression: evaluation order bug
Chet Ramey wrote in <8a61e01d-65c0-6c91-3575-399022fcb...@case.edu>: |On 12/30/22 3:44 PM, Steffen Nurpmeso wrote: | |> Digital, logical, liberal, yuck :) | |We channeling Supertramp here? For a nice Breakfast in America, yes. (Not really that. But really.) Ciao, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Arithmetic expression: evaluation order bug
On 1/4/23 12:21 PM, Steffen Nurpmeso wrote: Chet Ramey wrote in <8a61e01d-65c0-6c91-3575-399022fcb...@case.edu>: |On 12/30/22 3:44 PM, Steffen Nurpmeso wrote: | |> Digital, logical, liberal, yuck :) | |We channeling Supertramp here? For a nice Breakfast in America, yes. (Not really that. But really.) Well, now watch what you say, or they'll be calling you a radical. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
