Re: $((expr)) allows the hexadecimal constant "0x"

On Tue, Jan 16, 2024, at 4:43 PM, Chet Ramey wrote: > On 1/9/24 11:23 PM, Martin D Kealey wrote: >> The words “Integer constants follow the C language >> definition, without suffixes or character constants” were not added to the >> manual until June 2019 in the Devel branch (as commit >>

Re: $((expr)) allows the hexadecimal constant "0x"

On 1/9/24 11:23 PM, Martin D Kealey wrote: On Tue, 12 Dec 2023, 05:56 Zachary Santer, > wrote: On Mon, Dec 11, 2023 at 9:26 AM Chet Ramey mailto:chet.ra...@case.edu>> wrote: > Part of the issue here is that distros -- Red Hat, at least -- never >

Re: $((expr)) allows the hexadecimal constant "0x"

On Tue, 12 Dec 2023, 05:56 Zachary Santer, wrote: > On Mon, Dec 11, 2023 at 9:26 AM Chet Ramey wrote: > > Part of the issue here is that distros -- Red Hat, at least -- never > > upgrade the version of bash they started with. Red Hat will `support' > > bash-4.2 as long as they support RHEL 7. >

Re: $((expr)) allows the hexadecimal constant "0x"

On 12/11/23 7:23 PM, Martin D Kealey wrote: On Mon, 11 Dec 2023 at 06:55, Chet Ramey > wrote: It came up as a bug report in https://lists.gnu.org/archive/html/bug-bash/2019-06/mstheng00042.html

Re: $((expr)) allows the hexadecimal constant "0x"

Koichi Murase wrote in : |2023年12月10日(日) 15:58 Koichi Murase : |> 2023年12月10日(日) 14:13 Martin D Kealey : ... |> I'm not a big fan of `10#[-+]digits' and invalidating `10#' either ... |I checked the behaviors of different shells because I was interested |in them. They seem to vary more

Re: $((expr)) allows the hexadecimal constant "0x"

2023年12月10日(日) 15:58 Koichi Murase : > 2023年12月10日(日) 14:13 Martin D Kealey : > > But even if you still thought this was worth doing, it wasn't necessary to > > make $((10#)) completely illegal: Bash could look ahead and only intervene > > if the following character is '-' (affecting

Re: $((expr)) allows the hexadecimal constant "0x"

On Mon, 11 Dec 2023 at 06:55, Chet Ramey wrote: > It came up as a bug report in > > https://lists.gnu.org/archive/html/bug-bash/2019-06/mstheng00042.html > > > (part of the followup discussion after the second linked thread

Re: $((expr)) allows the hexadecimal constant "0x"

On 12/11/23 2:56 PM, Zachary Santer wrote: On Mon, Dec 11, 2023 at 9:26 AM Chet Ramey wrote: Part of the issue here is that distros -- Red Hat, at least -- never upgrade the version of bash they started with. Red Hat will `support' bash-4.2 as long as they support RHEL 7. To be fair to the

Re: $((expr)) allows the hexadecimal constant "0x"

On Mon, Dec 11, 2023 at 9:26 AM Chet Ramey wrote: > Part of the issue here is that distros -- Red Hat, at least -- never > upgrade the version of bash they started with. Red Hat will `support' > bash-4.2 as long as they support RHEL 7. To be fair to the Red Hat people, "my scripts used to work

Re: $((expr)) allows the hexadecimal constant "0x"

On 12/11/23 2:19 PM, Steffen Nurpmeso wrote: Chet Ramey wrote in : ... |It's still accepted in the devel branch, unless STRICT_ARITH_PARSING is |defined. There was a discussion about it in 2022: | |https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00045.html You surely mean

Re: $((expr)) allows the hexadecimal constant "0x"

Chet Ramey wrote in : ... |It's still accepted in the devel branch, unless STRICT_ARITH_PARSING is |defined. There was a discussion about it in 2022: | |https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00045.html You surely mean

Re: $((expr)) allows the hexadecimal constant "0x"

On Tue, Dec 12, 2023 at 12:10:02AM +0900, Koichi Murase wrote: > https://lists.gnu.org/archive/html/bug-bash/2019-06/threads.html#00039 Four years later, i=$(( ${i%%[!+-]*}10#${i#[-+]} )) is still horrible. Well, to be fair, five years since the original suggestion

Re: $((expr)) allows the hexadecimal constant "0x"

2023年12月11日(月) 23:37 Chet Ramey : > On 12/10/23 1:58 AM, Koichi Murase wrote: > > It's too late, but a better way could have been introducing the > > function-call syntax and supporting signed n-adic numbers through e.g. > > « int([-+]digits, n) ». > > You're 40 years too late. The [base#]number

Re: $((expr)) allows the hexadecimal constant "0x"

On 12/10/23 1:58 AM, Koichi Murase wrote: It's too late, but a better way could have been introducing the function-call syntax and supporting signed n-adic numbers through e.g. « int([-+]digits, n) ». You're 40 years too late. The [base#]number syntax was in ksh-83. -- ``The lyf so short,

Re: $((expr)) allows the hexadecimal constant "0x"

On 12/10/23 12:12 AM, Martin D Kealey wrote: And sometimes Bash isn't the thing that needs fixing. Maybe the manual needs to be clearer that "#" is not an "operator" like "+" or "/" but rather part of an unsigned integer constant (and that "-" is NOT part of such a constant). That syntax is

Re: $((expr)) allows the hexadecimal constant "0x"

On 12/9/23 9:15 PM, Zachary Santer wrote: Bash 4.2 on RHEL 7. Part of the issue here is that distros -- Red Hat, at least -- never upgrade the version of bash they started with. Red Hat will `support' bash-4.2 as long as they support RHEL 7. -- ``The lyf so short, the craft so long to

Re: $((expr)) allows the hexadecimal constant "0x"

On 12/11/23 7:49 AM, Zachary Santer wrote: On Sun, Dec 10, 2023 at 3:56 PM Chet Ramey wrote: Come on. Bash (and POSIX) define arithmetic in terms of how C does it, and that is an invalid C integer constant. It's not even shell-specific syntax like base#number; it's something that C defines. Is

Re: $((expr)) allows the hexadecimal constant "0x"

On Sun, Dec 10, 2023 at 3:56 PM Chet Ramey wrote: > Come on. Bash (and POSIX) define arithmetic in terms of how C does it, > and that is an invalid C integer constant. It's not even shell-specific > syntax like base#number; it's something that C defines. Is it worth it > trying to be helpful, or

Re: $((expr)) allows the hexadecimal constant "0x"

On 11/30/23 5:18 AM, Martin D Kealey wrote: When I said: > This change will break scripts that use $((10#$somevar)) to cope with > somevar having leading zeroes OR BEING EMPTY. Chet replied: this clearly invalid syntax "Clearly Invalid" is a matter of perspective. To me "no

Re: $((expr)) allows the hexadecimal constant "0x"

On 11/30/23 5:18 AM, Martin D Kealey wrote: If there's a bug tracking system beyond "threads in a mailing list", I'd like to know how I can get access to it. https://savannah.gnu.org/support/?group=bash -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars

Re: $((expr)) allows the hexadecimal constant "0x"

2023年12月10日(日) 14:13 Martin D Kealey : > But even if you still thought this was worth doing, it wasn't necessary to > make $((10#)) completely illegal: Bash could look ahead and only intervene > if the following character is '-' (affecting $((10#-digits)) but not > $((10#))). I'm not a big fan of

Re: $((expr)) allows the hexadecimal constant "0x"

On Sun, 10 Dec 2023, 12:15 Zachary Santer, wrote: > On Thu, Nov 30, 2023 at 5:19 AM Martin D Kealey > wrote: > > > > This change will break scripts that use $((10#$somevar)) to cope with > > > > somevar having leading zeroes OR BEING EMPTY. > Beside the point, but I wanted to point out how easy

Re: $((expr)) allows the hexadecimal constant "0x"

On Thu, Nov 30, 2023 at 5:19 AM Martin D Kealey wrote: > > > This change will break scripts that use $((10#$somevar)) to cope with > > > somevar having leading zeroes OR BEING EMPTY. Beside the point, but I wanted to point out how easy this is to work around. $ number=0196 $ unset somevar $

Re: $((expr)) allows the hexadecimal constant "0x"

Apropos the intentional breakage of ((10#$X)) I wrote (back in June 2023): > > Is there any chance this can be reversed before it becomes an official release? to which Chet replied: > This happened years ago. I have to admit that I'm finding that being a maintainer for a large suite of Bash

Re: $((expr)) allows the hexadecimal constant "0x"

On 6/29/23 1:28 PM, Martin D Kealey wrote: On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote: IIRC bash used to allow numeric constants of the BASE#DIGITS form even if the DIGITS part was empty. IOW: not only "64#0", but "64#" too was accepted as a valid zero constant. This no longer works

Re: $((expr)) allows the hexadecimal constant "0x"

On 6/29/23 1:17 PM, Steffen Nurpmeso wrote: I now only wondered why you did not also mention the bash bug $ echo $((0?2/0:7)) 7 $ echo $((0?2**-1:7)) -bash: 0?2**-1:7: exponent less than 0 (error token is ":7") Probably because it doesn't have anything to do with hex constants?

Re: $((expr)) allows the hexadecimal constant "0x"

On 6/29/23 5:45 AM, Denys Vlasenko wrote: Good day. IIRC bash used to allow numeric constants of the BASE#DIGITS form even if the DIGITS part was empty. IOW: not only "64#0", but "64#" too was accepted as a valid zero constant. Yes, that was clearly wrong, and it changed in bash-5.1.

Re: $((expr)) allows the hexadecimal constant "0x"

On Fri, Jun 30, 2023 at 03:28:36AM +1000, Martin D Kealey wrote: > On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote: > > > IIRC bash used to allow numeric constants of the > > BASE#DIGITS form even if the DIGITS part was empty. > > IOW: not only "64#0", but "64#" too was accepted > > as a

Re: $((expr)) allows the hexadecimal constant "0x"

On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote: > IIRC bash used to allow numeric constants of the > BASE#DIGITS form even if the DIGITS part was empty. > IOW: not only "64#0", but "64#" too was accepted > as a valid zero constant. > > This no longer works in 5.2.15, probably better than >

Re: $((expr)) allows the hexadecimal constant "0x"

Denys Vlasenko wrote in <54f87d1b-e700-e1d3-bf70-400c11145...@redhat.com>: |IIRC bash used to allow numeric constants of the |BASE#DIGITS form even if the DIGITS part was empty. |IOW: not only "64#0", but "64#" too was accepted |as a valid zero constant. | |This no longer works in 5.2.15,

$((expr)) allows the hexadecimal constant "0x"

Good day. IIRC bash used to allow numeric constants of the BASE#DIGITS form even if the DIGITS part was empty. IOW: not only "64#0", but "64#" too was accepted as a valid zero constant. This no longer works in 5.2.15, probably better than former behavior, "64#" looked quite confusing. However,