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.
Re: can't unset hash item with specific key
On Sun, Dec 12, 2021 at 08:47:21PM +0100, l.bash...@scarydevilmonastery.net
wrote:
> 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.
Just to say this unsets the element correctly:
k='[foo]'
unset -v 'a["$k"]'
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
bash manual on interactive shell
ref: https://www.gnu.org/software/bash/manual/html_node/What-is-an-Interactive-Shell_003f.html "An interactive shell is one started without non-option arguments, unles*s* -s is specified, without specifying the -c option, and whose input and error output are both connected to terminals (as determined by isatty(3)), or one started with the -i option." I'm a little confused about how all the and's and or's combine (I suppose it's obvious if you're a little more familiar with the material - but it would be great if it were possible to express this by indentation), but I'd actually decided to write in just to clarify that first line: "started without non-option arguments," Does "option arguments" mean "option*al* arguments"? If so, is the statement even correct? i.e. should it not be "started without optional arguments"? If the double-negative* is *actually correct, wouldn't the same sentiment be expressed by "started with only option(al?) arguments"? Double-negatives are inherently confusing, so it would be helpful to avoid them. -Mallika
Re: bash manual on interactive shell
On Sun, Dec 12, 2021, at 9:03 PM, Mallika wrote: > I'm a little confused about how all the and's and or's combine (I suppose > it's obvious if you're a little more familiar with the material - but it > would be great if it were possible to express this by indentation), It's a relatively confusing state of affairs. An unordered list might help. > but I'd actually decided to write in just to clarify that first line: > "started without non-option arguments," > > Does "option arguments" mean "option*al* arguments"? No. While all option arguments happen to be optional, not all optional arguments are options. An "option argument", roughly speaking, is an argument that begins with one or two hyphen-minuses and affects the configuration of the invoked shell. They are described here: https://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html > If the double-negative* is *actually correct, wouldn't the same sentiment > be expressed by "started with only option(al?) arguments"? Double-negatives > are inherently confusing, so it would be helpful to avoid them. Something like "with only option arguments" could easily be misunderstood as "with one or more option arguments". -- vq
`${array[index]=value}' broken in devel
To reproduce:
$ a=()
$ echo ${a[42]=foo}
Desktop Documents Downloads mpv-shot0001.jpg Music Pictures Public
Videos VirtualBox VMs
$ declare -p a
declare -a a=([42]="foo")
or
$ declare -A a
$ echo ${a[foo]=bar}
P�ϝU
$ declare -p a
declare -A a=([foo]="bar" )
Oğuz
Re: bash manual on interactive shell
Hi! Thanks for the quick response! And for clearing up what 'option arguments' means. I'm not sure I understood the last bit, though >Something like "with only option arguments" could easily be misunderstood as "with one or more option arguments". Are you saying that the 'only' could be easily ignored? i.e. "with one or more option arguments" is incorrect because it fails to specify that *no* non-option arguments may be used? Oh! You're saying the language used includes the case of no arguments at all, whereas the language I'm proposing may be interpreted as requiring option-arguments (which is what I had strugglingly understood it to mean) in that case, may I simply suggest: "started without any arguments, or with option arguments only" It is certainly more words, but unless you already have a solid understanding of non-option arguments (commands?) - in which case you're only having to perform one negation in your head - I think this construction makes it significantly easier to follow along. Ultimately, of course, it's up to you. I've made as much of a case for re-wording as I could :) Thank you again for your help, Mallika On Sun, Dec 12, 2021 at 10:08 PM Lawrence Velázquez wrote: > On Sun, Dec 12, 2021, at 9:03 PM, Mallika wrote: > > I'm a little confused about how all the and's and or's combine (I suppose > > it's obvious if you're a little more familiar with the material - but it > > would be great if it were possible to express this by indentation), > > It's a relatively confusing state of affairs. An unordered list > might help. > > > but I'd actually decided to write in just to clarify that first line: > > "started without non-option arguments," > > > > Does "option arguments" mean "option*al* arguments"? > > No. While all option arguments happen to be optional, not all > optional arguments are options. > > An "option argument", roughly speaking, is an argument that begins > with one or two hyphen-minuses and affects the configuration of the > invoked shell. They are described here: > > https://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html > > > If the double-negative* is *actually correct, wouldn't the same sentiment > > be expressed by "started with only option(al?) arguments"? > Double-negatives > > are inherently confusing, so it would be helpful to avoid them. > > Something like "with only option arguments" could easily be > misunderstood as "with one or more option arguments". > > -- > vq >
