$(()): "?:": false "assignment to non-variable"
Hey, sorry to come back, but when banging against ?: implementation i saw this bash 5.1.16 bug: $ bash -c 'I=3; echo "$((1?(I*=I):(I+=I)))";echo $I' 9 9 $ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I' bash: line 1: 1?(I*=I):I+=I: attempted assignment to non-variable (error token is "+=I") $ bash -c 'I=3; echo "$((1?I*=I:(I+=I)))";echo $I' 9 9 --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: $(()): "?:": false "assignment to non-variable"
On Jul 09 2022, Steffen Nurpmeso wrote: > $ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I' The third operand of ?: cannot contain an assignment expression, thus, like in C, this is parsed as `(1?(I*=I):I)+=I'. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: $(()): "?:": false "assignment to non-variable"
On 7/9/22 5:58 PM, Steffen Nurpmeso wrote: Hey, sorry to come back, but when banging against ?: implementation i saw this bash 5.1.16 bug: $ bash -c 'I=3; echo "$((1?(I*=I):(I+=I)))";echo $I' The parens override precedence. $ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I' bash: line 1: 1?(I*=I):I+=I: attempted assignment to non-variable (error token is "+=I") The normal rules of precedence apply, and the conditional expression on the rhs of the `:' can't contain an assignment, since the assignment operator has higher precedence. $ bash -c 'I=3; echo "$((1?I*=I:(I+=I)))";echo $I' The parens override precedence. -- ``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: reporting a bug: output of a long line, longer than fits on winow-size, breakes bash
On 7/10/22 8:35 AM, Anton Wessel wrote: I am working with Kubuntu 22.04 and KNOPPIX 9.1, bash version is reported by KNOPPIX: 5.1.4(1)-release (i686-pc-linux-gnu) My bash script contains many bash one-liners and comments. The one-liners are put into the history list by code like: history -s ': # ' After this script had been run once, I can scroll back in the lines of history list. I can stop scrolling when found a line, e.g.: : # ps -Flwwc --sort=start_time -t $(tty) Then I can remove the four characters at beginning of the line: ": # " and can execute this command. So far ok. When a one-liner is long, longer than fits on current window size, then problems in bash occure. This has nothing to do with what is the contents of the long line. Bash is broken by the fact that window size is exceeded. I can't reproduce this. It's probably your $PS1. -- ``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: $(()): "?:": false "assignment to non-variable"
Andreas Schwab wrote in : |On Jul 09 2022, Steffen Nurpmeso wrote: |> $ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I' | |The third operand of ?: cannot contain an assignment expression, thus, |like in C, this is parsed as `(1?(I*=I):I)+=I'. .. --End of Chet Ramey wrote in <52011ddb-824b-73d0-f1c8-c295ffa1f...@case.edu>: |On 7/9/22 5:58 PM, Steffen Nurpmeso wrote: ... |>$ bash -c 'I=3; echo "$((1?(I*=I):(I+=I)))";echo $I' | |The parens override precedence. | |>$ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I' |>bash: line 1: 1?(I*=I):I+=I: attempted assignment to non-variable \ |>(error token is "+=I") | |The normal rules of precedence apply, and the conditional expression on the |rhs of the `:' can't contain an assignment, since the assignment operator |has higher precedence. | | |>$ bash -c 'I=3; echo "$((1?I*=I:(I+=I)))";echo $I' | |The parens override precedence. Sorry for the noise then. And thanks for the explanation. (Assignment has lower.) --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: $(()): "?:": false "assignment to non-variable"
On 7/11/22 9:48 AM, Steffen Nurpmeso wrote: And thanks for the explanation. (Assignment has lower.) Yes. The assignment can't appear after the `:' because the *conditional* operator has higher precedence. -- ``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/
[the result of $[23**15] is wrong]
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -DSYSLOG_HISTORY -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-parentheses -Wno-format-security uname output: Linux ROCKY8-5-WL 4.18.0-348.el8.0.2.x86_64 #1 SMP Sun Nov 14 00:51:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.4 Patch Level: 20 Release Status: release Description: [Detailed description of the problem, suggestion, or complaint.] in bash the result of $[23**15] is wrong for example output [root@ROCKY8-5-02 ~]#echo $[23**15] 8380818432457522983 [root@ROCKY8-5-02 ~]#echo "23^15" | bc 266635235464391245607 [root@ROCKY8-5-02 ~]# Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
[the result of $[23**15] is wrong]
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -DSYSLOG_HISTORY -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-parentheses -Wno-format-security uname output: Linux ROCKY8-5-WL 4.18.0-348.el8.0.2.x86_64 #1 SMP Sun Nov 14 00:51:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.4 Patch Level: 20 Release Status: release Description: [Detailed description of the problem, suggestion, or complaint.] in bash the result of $[23**15] is wrong for example output [root@ROCKY8-5-02 ~]#echo $[23**15] 8380818432457522983 [root@ROCKY8-5-02 ~]#echo "23^15" | bc 266635235464391245607 [root@ROCKY8-5-02 ~]# Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
Re: [the result of $[23**15] is wrong]
On 7/11/22 10:14 AM, root@ROCKY8-5-WL.localdomain wrote: Bash Version: 4.4 Patch Level: 20 Release Status: release Description: [Detailed description of the problem, suggestion, or complaint.] in bash the result of $[23**15] is wrong for example output [root@ROCKY8-5-02 ~]#echo $[23**15] 8380818432457522983 Integer overflow. The result exceeds what can be represented in a signed 64-bit integer. -- ``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: [the result of $[23**15] is wrong]
On Mon, Jul 11, 2022 at 10:14:12PM +0800, root@ROCKY8-5-WL.localdomain wrote: > [Detailed description of the problem, suggestion, or complaint.] > in bash the result of $[23**15] is wrong > for example output > [root@ROCKY8-5-02 ~]#echo $[23**15] > 8380818432457522983 > [root@ROCKY8-5-02 ~]#echo "23^15" | bc > 266635235464391245607 First of all, the $[ ] syntax has been deprecated for two decades. You should be using $(( )) instead. Second, you've overflowed the variable type that bash is using on your platform (most likely a 64-bit signed integer type). unicorn:~$ bc -l [...] 2^63 9223372036854775808 23^15 266635235464391245607 On almost all modern platforms, bash uses a 64-bit signed integer type for its arithmetic. The value you're trying to compute here is larger than that type can hold.
Re: [the result of $[23**15] is wrong]
Date:Mon, 11 Jul 2022 22:10:38 +0800 (CST) From:root@ROCKY8-5-WL.localdomain Message-ID: <20220711141038.BE1E299F00@ROCKY8-5-WL.localdomain> Should we be attempting to reply to root@ROCKY8-5-WL.localdomain ? I'm not going to bother. | [root@ROCKY8-5-02 ~]#echo $[23**15] | 8380818432457522983 In addition to what Chet & Greg said: jacaranda$ echo '(23^15) % (2^64)' | bc 8380818432457522983 So, given the 64 bit limitation the answer is quite good... kre ps: Isn't $[ supposed to be obsolete?
Re: [the result of $[23**15] is wrong]
On Mon, Jul 11, 2022 at 10:41:40PM +0700, Robert Elz wrote: > Should we be attempting to reply to root@ROCKY8-5-WL.localdomain ? > > I'm not going to bother. Same. > ps: Isn't $[ supposed to be obsolete? It's deprecated and undocumented. But Chet never removed the actual code, presumably in order to keep old scripts running.
Re: $(()): "?:": false "assignment to non-variable"
On Mon, Jul 11, 2022 at 8:22 AM Chet Ramey wrote: > The normal rules of precedence apply, and the conditional expression on the > rhs of the `:' can't contain an assignment, since the assignment operator > has higher precedence. > > This excerpt from the Bash man page ARITHMETIC EVALUATION section: expr?expr:expr conditional operator = *= /= %= += -= <<= >>= &= ^= |= assignment indicates that assignment has a lower precedence than the overall ternary without specifying precedence of individual parts of it. Interestingly, zsh requires both assignments to be parenthesized and ksh doesn't require either. Bash is like C and ksh is like cpp.
readline: remove redisplay in `rl_display_search`
Avoid a double redisplay when using reverse incremental search for
example. `rl_message` already calls `(*rl_redisplay_function)` before
returning, in all cases (`USE_VARARGS` or not).
---
Hello,
this was tested on bash-5.2-testing, Bash-5.2-rc1 release.
It should also apply to bash-5.1.
It looked straightforward enough to me once I spotted it.
I hope it is.
Frédéric Moulins
diff --git a/lib/readline/isearch.c b/lib/readline/isearch.c
index 3e398a6c..60fab5d7 100644
--- a/lib/readline/isearch.c
+++ b/lib/readline/isearch.c
@@ -194,7 +194,6 @@ rl_display_search (char *search_string, int flags, int
where)
rl_message ("%s", message);
xfree (message);
- (*rl_redisplay_function) ();
}
static _rl_search_cxt *
