bash 5.2 bad substitution for ${x:+${x}[}
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux … 5.18.16-…-amd64 #1 SMP PREEMPT_DYNAMIC Debian
5.18.16-… (2022-…) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: !PATCHLEVEL!
Release Status: release
Description:
Some substitutions that used to work pre 5.2 are failing starting in
5.2. I did a git bisect on that, it's the initial 5.2 commit which
broke this,
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=bash-5.2&id=74091dd4e8086db518b30df7f222691524469998.
According to my reproducing example below, this appears to be due to a
combination of conditional substitution, a variable enclosed in curly
braces and an unbalanced opening square bracket that I think should
only be considered as text without any semantic relevance in this
position.
Repeat-By:
bash -c 'x=""; echo "a${x:+${x}[}b"'
Work-around:
Omit the inner curly braces, i.e. use "a${x:+$x[}b".
Re: bash 5.2 bad substitution for ${x:+${x}[}
On 10/20/22 5:03 AM, Martin von Gagern wrote:
Bash Version: 5.2
Patch Level: !PATCHLEVEL!
Release Status: release
Description:
Some substitutions that used to work pre 5.2 are failing starting in
5.2. I did a git bisect on that, it's the initial 5.2 commit which
broke this,
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=bash-5.2&id=74091dd4e8086db518b30df7f222691524469998.
According to my reproducing example below, this appears to be due to a
combination of conditional substitution, a variable enclosed in curly
braces and an unbalanced opening square bracket that I think should
only be considered as text without any semantic relevance in this
position.
Thanks for the report. This came up a couple weeks ago in
https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00022.html
and is fixed in the devel branch. I've attached the patch that fixes it.
Chet
--
``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/
*** ../bash-5.2-patched/subst.c 2022-10-05 10:22:02.0 -0400
--- subst.c 2022-10-06 15:19:08.0 -0400
***
*** 1799,1802
--- 1804,1810
}
+ #define PARAMEXPNEST_MAX 32 // for now
+ static int dbstate[PARAMEXPNEST_MAX];
+
/* Extract a parameter expansion expression within ${ and } from STRING.
Obey the Posix.2 rules for finding the ending `}': count braces while
***
*** 1829,1832
--- 1837,1842
return (extract_heredoc_dolbrace_string (string, sindex, quoted, flags));
+ dbstate[0] = dolbrace_state;
+
pass_character = 0;
nesting_level = 1;
***
*** 1853,1856
--- 1863,1868
if (string[i] == '$' && string[i+1] == LBRACE)
{
+ if (nesting_level < PARAMEXPNEST_MAX)
+ dbstate[nesting_level] = dolbrace_state;
nesting_level++;
i += 2;
***
*** 1865,1868
--- 1877,1881
if (nesting_level == 0)
break;
+ dolbrace_state = (nesting_level < PARAMEXPNEST_MAX) ?
dbstate[nesting_level] : dbstate[0];/* Guess using initial state */
i++;
continue;
Re: Regression in 5.2 in arithmetic comparison
On 10/18/22 3:55 PM, Glenn Jackman wrote:
Bash Version: 5.2
Patch Level: 0
Release Status: release
Description:
an arithmetic comparison where an array index contains an array
element fails.
Repeat-By:
in bash 5.2
$ coins[3]=10 i=3 C[5]=42 p=15
$ # comparison throws error
$ (( C[p - coins[i]] > 10)) && echo Y || echo N
bash: p - coins\[i\]: syntax error: invalid arithmetic
operator (error token is "\[i\]")
$ # but arithmetic expression is OK
$ echo $(( C[p - coins[i]] ))
42
Thanks for the report. It's not the array reference that triggers it, but
the arithmetic comparison. If you'd added the comparison to the arithmetic
expansion, you'd have seen the same error.
The cause is the new code in bash-5.2 to prevent multiple evaluation of
array subscripts. The fix is to exempt the presence of `<' and `>' from
that treatment, since they're not treated specially in that context.
I've attached the trivial patch.
Chet
--
``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/
*** ../bash-20221015/subst.c2022-10-18 10:47:33.0 -0500
--- subst.c 2022-10-20 11:41:07.0 -0500
***
*** 3825,3828
--- 3825,3832
#endif
+ /* We don't perform process substitution in arithmetic expressions, so don't
+bother checking for it. */
+ #define ARITH_EXP_CHAR(s) (s == '$' || s == '`' || s == CTLESC || s == '~')
+
/* If there are any characters in STRING that require full expansion,
then call FUNC to expand STRING; otherwise just perform quote
***
*** 4034,4038
while (string[i])
{
! if (EXP_CHAR (string[i]))
break;
else if (string[i] == '\'' || string[i] == '\\' || string[i] == '"')
--- 4038,4042
while (string[i])
{
! if (ARITH_EXP_CHAR (string[i]))
break;
else if (string[i] == '\'' || string[i] == '\\' || string[i] == '"')
Re: Checking evolution of information about required symbols
On 10/19/22 8:32 AM, Markus Elfring wrote: Hello, Some information was published with the subject “Bash-5.2 Release available” on 2022-09-26. https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00056.html https://www.mail-archive.com/info-gnu@gnu.org/msg03096.html “… Bash can be linked against an already-installed Readline library rather than the private version in lib/readline if desired. Only readline-8.1 and later versions are able to provide all of the symbols that bash-5.2 requires; …” Sorry, that's a typo. It should read readline-8.2. In general, a specific version of bash requires the same version of readline it ships with in lib/readline. -- ``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/
