Behaviour of test -v with assoc array and quote character in key
Hi list,
I've found what I belive to be a bug in how `test -v` expands the key in an
associative array. The following minimal test case demonstrates the
problem:
declare -A array
mytest () {
array["$1"]=123
test -v array["$1"]
printf 'test -v array[%s]; $?=%s\n' "$1" "$?"
}
mytest 'a' # prints: test -v array[a]; $?=0
mytest '"' # prints: test -v array["]; $?=1
echo "keys: ${!array[*]}" # prints: keys: " a
With a regular alphanumeric key `test -v` will return zero, indicating the
array element exists. However if we specify a variable that expands to
something containing the double quote character the test doesn't succeeed
indicating the key doesn't exist though it does as we can observe by the
expansion of ${!array[*]}.
Do you think this intended behaviour or a real bug?
Tested on Debian buster, with bash_5.0-4 ($BASH_VERSION="5.0.3(1)-release")
and git master commit 76404c85d492c001f59f2644074333ffb7608532.
Thanks,
Daniel
PS: Please keep me in CC as I'm not subscribed.
Re: syntax error while parsing a case command within `$(...)'
On Feb 14 2021, Eli Schwartz wrote: > On 2/14/21 3:35 PM, Andreas Schwab wrote: >> On Feb 14 2021, Eli Schwartz wrote: >> >>> Just a running trend that esac does not get recognized without a >>> separator. >> >> $ bash -c 'case x in x) esac' > > The thread title does mention $(...) as the relevant context up for > discussion. Apologies if my terseness made you think I've moved off of > the thread subject; I did not do so. It's still a counterexample. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: syntax error while parsing a case command within `$(...)'
On 2/14/21 3:35 PM, Andreas Schwab wrote: > On Feb 14 2021, Eli Schwartz wrote: > >> Just a running trend that esac does not get recognized without a >> separator. > > $ bash -c 'case x in x) esac' The thread title does mention $(...) as the relevant context up for discussion. Apologies if my terseness made you think I've moved off of the thread subject; I did not do so. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: syntax error while parsing a case command within `$(...)'
On Feb 14 2021, Eli Schwartz wrote: > Just a running trend that esac does not get recognized without a > separator. $ bash -c 'case x in x) esac' Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: syntax error while parsing a case command within `$(...)'
> On Feb 14, 2021, at 3:00 PM, Oğuz wrote: > > 14 Şubat 2021 Pazar tarihinde Dale R. Worley yazdı: > >> Before we worry about what to change, I want to note that the original >> example is syntactically incorrect. The example is >> >> $ bash -c ': $(case x in x) esac)' >> >> But the manual page makes it clear that each case must be ended with >> ";;". > > > `;;' is optional for the last case item. For reference: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_05 For comparison: % ksh -c ': $(case x in x) esac)'; echo $? 0 % zsh -c ': $(case x in x) esac)'; echo $? 0 % dash -c ': $(case x in x) esac)'; echo $? 0 % yash -c ': $(case x in x) esac)'; echo $? 0 % bash -c ': $(case x in x) esac)'; echo $? bash: -c: line 1: unexpected EOF while looking for matching `)' bash: -c: line 2: syntax error: unexpected end of file 2 vq
Re: syntax error while parsing a case command within `$(...)'
On 2/14/21 2:43 PM, Dale R. Worley wrote: > Before we worry about what to change, I want to note that the original > example is syntactically incorrect. The example is > > $ bash -c ': $(case x in x) esac)' > > But the manual page makes it clear that each case must be ended with > ";;". > >case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac > > Now, I haven't investigated what cleverness Bash uses, but all the cases > I've tested that conform to the case syntax are handled correctly inside > this $(...): > > $ bash -c ': $( case x in x) : ;; esac )' > $ bash -c ': $( case x in x) true ;; esac )' > $ bash -c ': $( case x in (x) true ;; esac )' > > It even works with the degenerate case where there are no coices, though > writing it is hard because "esac" is a keyword: > > $ bash -c ': $( case x in > more> esac )' > > This is with an old version, 4.2.53(1). $ bash -c ': $( case x in x) esac ); echo $?' 0 Doesn't seem like a special power of your degenerate case. Just a running trend that esac does not get recognized without a separator. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: syntax error while parsing a case command within `$(...)'
14 Şubat 2021 Pazar tarihinde Dale R. Worley yazdı: > Before we worry about what to change, I want to note that the original > example is syntactically incorrect. The example is > > $ bash -c ': $(case x in x) esac)' > > But the manual page makes it clear that each case must be ended with > ";;". `;;' is optional for the last case item. > >case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac > > Now, I haven't investigated what cleverness Bash uses, but all the cases > I've tested that conform to the case syntax are handled correctly inside > this $(...): > > $ bash -c ': $( case x in x) : ;; esac )' > $ bash -c ': $( case x in x) true ;; esac )' > $ bash -c ': $( case x in (x) true ;; esac )' > > It even works with the degenerate case where there are no coices, though > writing it is hard because "esac" is a keyword: > > $ bash -c ': $( case x in > more> esac )' `case x in esac' (without the linebreak) works fine outside the command substitution. > This is with an old version, 4.2.53(1). > > Dale > -- Oğuz
Re: syntax error while parsing a case command within `$(...)'
Before we worry about what to change, I want to note that the original example is syntactically incorrect. The example is $ bash -c ': $(case x in x) esac)' But the manual page makes it clear that each case must be ended with ";;". case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac Now, I haven't investigated what cleverness Bash uses, but all the cases I've tested that conform to the case syntax are handled correctly inside this $(...): $ bash -c ': $( case x in x) : ;; esac )' $ bash -c ': $( case x in x) true ;; esac )' $ bash -c ': $( case x in (x) true ;; esac )' It even works with the degenerate case where there are no coices, though writing it is hard because "esac" is a keyword: $ bash -c ': $( case x in more> esac )' This is with an old version, 4.2.53(1). Dale
Re: syntax error while parsing a case command within `$(...)'
14 Şubat 2021 Pazar tarihinde Robert Elz yazdı: > > That's a step up on outright rejecting them, which they do from time > to time. I don't much care, anyone who really cares about receiving > e-mail shouldn't be using gmail. > What else am I gonna use? It's free -- Oğuz
Re: syntax error while parsing a case command within `$(...)'
Date:Sun, 14 Feb 2021 13:14:29 + From:Stephane Chazelas Message-ID: <20210214131429.yxr5egs7zs6fe...@chazelas.org> | ITYM Brian Fox. Yes, probably ... my memory is pathetic, and that was all a long time ago. kre
Re: syntax error while parsing a case command within `$(...)'
2021-02-14 18:02:52 +0700, Robert Elz: [...] > | I guess you are using Bash for so many years, > > Yes, since Paul Fox created and maintained it (version 1). It allowed > me to escape from csh. ITYM Brian Fox. Maybe the confusion comes from zsh's Paul Falstad. -- Stephane
Re: syntax error while parsing a case command within `$(...)'
Date:Sun, 14 Feb 2021 17:00:06 +0800 From:Koichi Murase Message-ID: | I guess you are using Bash for so many years, Yes, since Paul Fox created and maintained it (version 1). It allowed me to escape from csh. | but it was fixed in Bash 4.0 (2009). That is good to know. I (these days, and really forever) only use bash as an interactive shell, not for scripts, and don't tend to use constructs like the ones in question interactively. And: oguzismailuy...@gmail.com said: | By the way, Gmail's marking your emails as spam again. That's a step up on outright rejecting them, which they do from time to time. I don't much care, anyone who really cares about receiving e-mail shouldn't be using gmail. kre
Re: syntax error while parsing a case command within `$(...)'
2021年2月14日(日) 17:16 Oğuz : >> This is interesting. I think this is just an oversight. A quick fix >> like the attached patch should be fine. [ Note: The patch seems to >> work fine, but I haven't carefully read the code, so I'm not sure if >> this fix is really correct. ] > > It seems to be on the right track but incomplete: > >$ ./bash -c '$(case x in x) ;; x) esac)' > ./bash: -c: line 1: unexpected EOF while looking for matching `)' > ./bash: -c: line 2: syntax error: unexpected end of file > Yeah, let's wait for Chet's fix. I haven't read the entire code of this long function `parse_comsub ()' so cannot properly fix it soon. I think the problem has been pinpointed by the patch, so I expect it can be right fixed by Chet. -- Koichi
Re: syntax error while parsing a case command within `$(...)'
14 Şubat 2021 Pazar tarihinde Koichi Murase yazdı: > 2021年2月14日(日) 15:41 Andreas Kusalananda Kähäri : > > And using (x) doesn't help: > > > > % bash -c ': $(case x in (x) esac)' > > bash: -c: line 1: unexpected EOF while looking for matching `)' > > bash: -c: line 2: syntax error: unexpected end of file > > This is interesting. I think this is just an oversight. A quick fix > like the attached patch should be fine. [ Note: The patch seems to > work fine, but I haven't carefully read the code, so I'm not sure if > this fix is really correct. ] > It seems to be on the right track but incomplete: $ ./bash -c '$(case x in x) ;; x) esac)' ./bash: -c: line 1: unexpected EOF while looking for matching `)' ./bash: -c: line 2: syntax error: unexpected end of file -- Oğuz
Re: export loses error
2021-02-09 10:23:51 -0500, Chet Ramey: [...] > It's the assignment statement that's the oddball here; it's the only place > where the exit status from a command substitution has any effect. This is a > POSIX (maybe ksh) invention to provide assignment statements with a useful > exit status. [...] It was already like that in the Bourne shell, the shell that introduced command substitution in the late 70s. Here on a PDP11 emulator running Unix V7: PDP-11 simulator V3.8-1 Disabling XQ @boot New Boot, known devices are hp ht rk rl rp tm vt : rl(0,0)rl2unix mem = 177856 # false # echo $? 1 # a=`false` # echo $? 1 -- Stephane
Re: syntax error while parsing a case command within `$(...)'
2021年2月14日(日) 15:41 Andreas Kusalananda Kähäri : > And using (x) doesn't help: > > % bash -c ': $(case x in (x) esac)' > bash: -c: line 1: unexpected EOF while looking for matching `)' > bash: -c: line 2: syntax error: unexpected end of file This is interesting. I think this is just an oversight. A quick fix like the attached patch should be fine. [ Note: The patch seems to work fine, but I haven't carefully read the code, so I'm not sure if this fix is really correct. ] 2021年2月14日(日) 6:23 Robert Elz : > [...] > > This problem has been known for a LONG time, without it being fixed. I guess you are using Bash for so many years, but it was fixed in Bash 4.0 (2009). You can see the result of the following command: $ bash-4.0 -c ': $(case x in x) :; esac)' 2021年2月14日(日) 6:23 Robert Elz : > Fixing it would take major work in the parser, so the chances of it > happening are not all that great. The case reported here appears to be just an oversight in the fix of Bash 4.0, so I guess an additional fix should be relatively easy. -- Koichi 0001-fix-parsing-of-case-x-in-x-esac.patch Description: Binary data
Re: man bash-builtins
2021-02-12 19:33:33 -0700, ron: > In the Synopsis section, the builtin `caller` is not included. Several > keywords are listed as builtins: [, if, until and while. You're probably refering to the bash-builtins.1 man page shipped with Debian. If you look at the bottom, you'll see that man page is from bash 2.05a. If you look at the CHANGES file in bash-2.05b released in 2002, you'll see: > l. Removed the reserved words from the `bash-builtins' manual > page. The doc/builtins.1 in current versions of bash doesn't have the problem, though it's missing the "readarray" builtin (IMO, the better name for the "mapfile" builtin) and lists "bash" itself as a builtin. "[" itself *is* a builtin, (an alias for "test") not a keyword. You may want to raise the issue with Debian instead. You'll notice that doc/builtins.1 is very short, just a header and then .SO's the relevant section of the bash.1 man page. That file could easily be automatically generated based on the output of the "enable" builtin for instance. Personally, to learn about a bash builtin, I just run info bash builtin -- Stephane
