Re: Arithmetic pow results incorrect in arithmetic expansion.

Date:Sat, 9 Jan 2021 14:45:49 +0900 From:Hyunho Cho Message-ID: | I didn't know that all other shells work the same. Not "all" other shells, most don't implement exponentiation at all, since it isn't a standard C operator. Just the ones that happen to implement

Re: Arithmetic pow results incorrect in arithmetic expansion.

I didn't know that all other shells work the same. Thanks for the clarification. 2021년 1월 9일 (토) 오후 2:29, Lawrence Velázquez 님이 작성: > > On Jan 8, 2021, at 11:19 PM, Hyunho Cho wrote: > > > > Machine: x86_64 > > OS: linux-gnu > > Compiler: gcc > > Compilation CFLAGS: -g -O2 > > -fdebug-prefix-

Re: Arithmetic pow results incorrect in arithmetic expansion.

> On Jan 8, 2021, at 11:19 PM, Hyunho Cho wrote: > > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. > -fstack-protector-strong -Wformat -Werror=format-security -Wall > -Wno-parentheses -Wno-format-security > uname ou

Re: Arithmetic pow results incorrect in arithmetic expansion.

9 Ocak 2021 Cumartesi tarihinde Hyunho Cho yazdı: > > i have tested below in gnome calculator, Qalculate, gawk, perl > and all results in -4 but bash is 4 > > $ awk 'BEGIN { print -2 ^ 2 }' > -4 > > $ perl -E 'say -2 ** 2' > -4 > > $ echo $(( -2 ** 2 )) # only bash results in 4

Arithmetic pow results incorrect in arithmetic expansion.

Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux EliteBook 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:2

Re: declare accept + before =

Le 08/01/2021 à 15:26, Chet Ramey écrivait : On 1/8/21 8:45 AM, Léa Gris wrote: Just curious why it accepts a + before = Try it with a variable that already has a value. OMG I feel stupid now! -- Léa Gris

Re: Associative array keys are not reusable in (( command

On Fri, Jan 8, 2021 at 5:44 PM Chet Ramey wrote: > On 1/8/21 10:24 AM, Oğuz wrote: > > This situation is why bash-5.0 introduced the `assoc_expand_once' > option. > > But it allows arbitrary command injection. > > If you want to run array keys through word expansions, this is one > potential

Re: Associative array keys are not reusable in (( command

On 1/8/21 10:24 AM, Oğuz wrote: 8 Ocak 2021 Cuma tarihinde Chet Ramey > yazdı: On 1/8/21 5:20 AM, Oğuz wrote: See:      $ declare -A assoc=($'\n\'' 42)      $ for key in "${!assoc[@]}"; do (( assoc[$key]++ )); done      bash:

Re: Associative array keys are not reusable in (( command

8 Ocak 2021 Cuma tarihinde Chet Ramey yazdı: > On 1/8/21 5:20 AM, Oğuz wrote: > >> See: >> >> $ declare -A assoc=($'\n\'' 42) >> $ for key in "${!assoc[@]}"; do (( assoc[$key]++ )); done >> bash: ((: assoc[ >> ']++ : bad array subscript (error token is "assoc[ >> ']++ ")

Re: declare -p name=value thinks 'name=value' is variable

On Fri, Jan 8, 2021 at 4:06 PM Chet Ramey wrote: > No. `declare -p' does not accept assignment statements. > The synopsis in the documentation doesn't make it clear, though. It shows only one case with -p and assignment, while the similar case of export -p is listed separately from the other for

Re: declare accept + before =

On 1/8/21 8:45 AM, Léa Gris wrote: Just curious why it accepts a + before = Try it with a variable that already has a value. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhtt

Re: Associative array keys are not reusable in (( command

On 1/8/21 5:20 AM, Oğuz wrote: See: $ declare -A assoc=($'\n\'' 42) $ for key in "${!assoc[@]}"; do (( assoc[$key]++ )); done bash: ((: assoc[ ']++ : bad array subscript (error token is "assoc[ ']++ ") $ $ (( assoc[${key@Q}]++ )) bash: ((: assoc[$'\n\'']++

Re: declare -p name=value thinks 'name=value' is variable

On 1/8/21 4:05 AM, William Park wrote: Another issue I came across. declare -p name=value thinks 'name=value' is the variable. My reading of manpage seems to say 'name' should be used, but not sure. Is this a bug? No. `declare -p' does not accept assignment statements. -- ``The lyf so

declare accept + before =

Just curious why it accepts a + before = unset a; declare a+=hello; typeset -p a bash, version 5.0.17(1)-release wrote: > declare -- a="hello" -- Léa Gris

Re: declare -p name=value thinks 'name=value' is variable

On 1/8/21 4:05 AM, William Park wrote: Another issue I came across. declare -p name=value thinks 'name=value' is the variable. My reading of manpage seems to say 'name' should be used, but not sure. Is this a bug? Workaround is, of course, use separate lines, declare name=value

Re: Associative array keys are not reusable in (( command

2021年1月8日(金) 20:07 Oğuz : > On Fri, Jan 8, 2021 at 2:14 PM Koichi Murase wrote: >> There is no reason to introduce a different expansion rule of >> `((...))' from that of `$((...))'. > > But there already is a different expansion rule. While `(( > assoc['$key']++ ))' works, `: $(( assoc['$key']++

Re: Associative array keys are not reusable in (( command

On Fri, Jan 8, 2021 at 2:14 PM Koichi Murase wrote: > This topic actually pops up occasionally. FYI, you can also see the > following discussions: > > https://lists.gnu.org/archive/html/bug-bash/2014-06/msg3.html > https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00154.html > https://l

Re: Associative array keys are not reusable in (( command

This topic actually pops up occasionally. FYI, you can also see the following discussions: https://lists.gnu.org/archive/html/bug-bash/2014-06/msg3.html https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00154.html https://lists.gnu.org/archive/html/bug-bash/2015-02/msg00066.html 2021年1月

Associative array keys are not reusable in (( command

See: $ declare -A assoc=($'\n\'' 42) $ for key in "${!assoc[@]}"; do (( assoc[$key]++ )); done bash: ((: assoc[ ']++ : bad array subscript (error token is "assoc[ ']++ ") $ $ (( assoc[${key@Q}]++ )) bash: ((: assoc[$'\n\'']++ : bad array subscript (error token is "a

Re: local -p var prints nothing

> On Jan 8, 2021, at 3:50 AM, William Park wrote: > > I don't know if it's a bug. Manpage says "local" builtin takes all the > options that "declare" takes. But, "local -p var" doesn't print > anything, where as "declare -p var" does. > > f1() > { >local a=123 >local -p a > } > > f2()

declare -p name=value thinks 'name=value' is variable

Another issue I came across. declare -p name=value thinks 'name=value' is the variable. My reading of manpage seems to say 'name' should be used, but not sure. Is this a bug? Workaround is, of course, use separate lines, declare name=value declare -p name -- William Park

local -p var prints nothing

I don't know if it's a bug. Manpage says "local" builtin takes all the options that "declare" takes. But, "local -p var" doesn't print anything, where as "declare -p var" does. f1() { local a=123 local -p a } f2() { local a=123 declare -p a } f1 # prints nothing f2 #