can't unset hash item with specific key
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 h2 5.15.0-2-amd64 #1 SMP Debian 5.15.5-1 (2021-11-26)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 12
Release Status: release
Description:
making left square bracket char ([) part of the key into a hash causes
unset to silently fail when trying to unset that specific hash item.
The position of left square bracket char in the string used as key
doesn't
matter. unset also fails when the key is a single [ character.
Please refer to the following script which attempts to demonstrate this
quirk.
Repeat-By:
# diagnostic shows remains of hash after attempts to unset single item.
show() { echo "$1, ${#a[@]} items in a: a['${!a[@]}']=${a['[foo]']}"; }
# prepare test scenario
declare -A a# make "a" a hash
a['[foo]']="bar"# assign "bar" to item keyed [foo]
show "good" # correctly output item, show correct
item count
# intention is to get rid of the item again, by unsetting the single item, not
the whole array.
# several ways of quoting are attempted here
unset "a['[foo]']" # try to remove item
show "wrong"# can still output item, item still
counts
unset 'a["[foo]"]' # try to remove item
show "wrong"# can still output item, item still
counts
unset 'a[[foo]]'# try to remove item
show "wrong"# can still output item, item still
counts
unset "a[[foo]]"# try to remove item
show "wrong"# can still output item, item still
counts
unset "a[\[foo]]" # try to remove item
show "wrong"# can still output item, item still
counts
unset "a["\[foo]"]" # try to remove item
show "wrong"# can still output item, item still
counts
unset "a['['foo]]" # try to remove item
show "wrong"# can still output item, item still
counts
a["[foo]"]="" # Best I can currently do
show "set empty, item still counted"# item still there though contents are
empty string.
bash dislikes empty functions or flow control bodies
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 latitude 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2 (2021-12-18)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Even if descriptions of situations where this problem occurs may sound
contrived, those situation exist and require me to catch this problem
with additional code:
a: defining an empty function will throw a syntax error
b: defining an empty bodies flow control construct will thow a syntax error
While it may be debatable whether such construct could serve any purpose
(they actually can), perceived lack of purpose doesn't qualify them as
syntactically wrong. They aren't. Would they be syntactically wrong,
the syntax error would continue to exist after adding a harmless
"no operation" equivalent.
You may justifiable ask "so why not simply use the workaround by adding
a no operation equivalent" - answer is that it may not be me in person
creating a function or a flow control construct - the script may do too,
in accordance with input it received (this is the mentioned part where the
description may sound contrived, but isn't). Therefore I must protect the
script at this point from generating empty functions or flow control
constructs.
You may have guessed here that this is going towards some sort of meta
programming, and a fuller view of the reason for reporting the bug can be
obtained at https://github.com/Bushmills/yoda, specifically
at https://github.com/Bushmills/yoda/issues/7
Measures to circumvent the problem can be found in file
https://github.com/Bushmills/yoda/blob/main/yoda at around line 1900
(at this time) on those lines with text "empty function" in the description
Repeat-By:
bar() { ; }
foo() { if true; then ; fi; }
foo() { while :; do ; done; }
Fix:
In cases where this problem arises, I tend to synthesise the closest
approximation of a "no operation" I know about, which is ":":
bar() { :; }
foo() { if true; then :; fi; }
foo() { while :; do :; done; }
