Re: bash encountered a coredump issue with stepping on memory

[wang yuhang]

> Is this at the same point as the core dump in your previous message?

yes

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

[Zachary Santer]

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 is it better to follow the standard you say you
> do?

Just so everyone's clear:

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -march=nocona -msahf -mtune=generic -O2 -pipe
-D_STATIC_BUILD
uname output: MINGW64_NT-10.0-19045 Zack2021HPPavilion 3.4.10.x86_64
2023-11-30 06:09 UTC x86_64 Msys
Machine Type: x86_64-pc-msys

Bash Version: 5.2
Patch Level: 21
Release Status: release

$ printf '%s\n' "$(( 0x ))";
0

In my opinion, it would be better to have this not treated as valid,
for the same reason that 10# is no longer treated as valid. And it
would probably do less script-breaking than invalidating 10# did.

Sorry if that's already been done under the devel branch. I didn't
really get that vibe.

- Zack

Re: Sv: TAB completion bug

[Chet Ramey]

On 12/10/23 7:23 PM, Ole Tange wrote:

*Fra:* Chet Ramey 

On 12/5/23 6:46 PM, Ole Tange via Bug reports for the GNU Bourne Again

SHell wrote:


  For the (admitedly weirdly named) dirs below TAB completion does not work 
correctly.



Thanks for the report. Where did you encounter these directory names?


Test purposes.


Fair enough.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Chet Ramey]

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 it worth it
trying to be helpful, or is it better to follow the standard you say you
do?


Just so everyone's clear:

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -march=nocona -msahf -mtune=generic -O2 -pipe
-D_STATIC_BUILD
uname output: MINGW64_NT-10.0-19045 Zack2021HPPavilion 3.4.10.x86_64
2023-11-30 06:09 UTC x86_64 Msys
Machine Type: x86_64-pc-msys

Bash Version: 5.2
Patch Level: 21
Release Status: release

$ printf '%s\n' "$(( 0x ))";
0

In my opinion, it would be better to have this not treated as valid,
for the same reason that 10# is no longer treated as valid. And it
would probably do less script-breaking than invalidating 10# did.


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

in the context of the bash arithmetic parser trying to be too helpful.
It's clearly invalid, and no one should be using it.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Chet Ramey]

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 lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Chet Ramey]

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 documented as part of the description of an integer
constant. The `+' or `-' operators aren't mentioned anywhere in that
description. `#' not listed in the table of arithmetic operators. The
`base#' is described as optional, while the `n' following it is not. How
much clearer do you want it to be?


--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[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 syntax was in ksh-83.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Koichi Murase]

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 syntax was in ksh-83.

Sorry for my confusing writing, but I meant that instead of dropping
the support for `10#' in Bash 5.1, we could have supported something
like « int([-+]digits, n) » or « strtol([-+]digits, n) ». Maybe I
misunderstand it, but AFAIU, `10#' was dropped in the following
thread, which discusses `10#$X' where e.g. X='-10':

https://lists.gnu.org/archive/html/bug-bash/2019-06/threads.html#00039

I thought the motivation for dropping the support for `10#' was to
make `10#-10' unambiguous when ksh's treatment of « 10#[-+]digits »
would be added to Bash in the future. However, if « int([-+]digits, n)
» is added instead, « 10#[-+]digits » does not need to be added to
Bash, the ambiguity in « 10#[-+]digits » does not arise, and `10#' can
continue to mean 0 for backward compatibility.

Anyway, it's too late; `10#' is already removed.

--
Koichi

Ability to display parameters as global with `declare -gp`

[Albert Akchurin]

Configuration Information [Automatically generated, do not change]:

Machine: x86_64

OS: linux-gnu

Compiler: gcc

Compilation CFLAGS: -g -O2

uname output: Linux fs 6.5.11-7-pve #1 SMP PREEMPT_DYNAMIC PMX 6.5.11-7
(2023-12-05T09:44Z) x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu


Bash Version: 5.2

Patch Level: 21

Release Status: release


Description:

   `declare -p` loses the global flag passed to variable/array on
definition.

   I think this behaviour is reasonable, but sometimes I need to
save/restore

   Global variables in the function. Unfortunately when I source saved

   variables from a function the variables are scoped to that function.

   Could you please add the ability to display all the variables as
global

   when using '-g' along with '-p' option? No internal checks needed,
just

   Put the '-g' flag when displaying each variable definition requested.


Repeat-By:

   # define a variable:

   declare -g A=33

   # display it

   declare -p A

   declare -- A="33"


   # I would like to be able to do this:

   declare -gp A

   # expected result:

   declare -g A="33"

   # unfortunately, currently it is the same as `declare -p`

`declare -f` incorrectly displays `coproc` statement

[Albert Akchurin]

Configuration Information [Automatically generated, do not change]:

Machine: x86_64

OS: linux-gnu

Compiler: gcc

Compilation CFLAGS: -g -O2

uname output: Linux fs 6.5.11-7-pve #1 SMP PREEMPT_DYNAMIC PMX 6.5.11-7
(2023-12-05T09:44Z) x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu


Bash Version: 5.2

Patch Level: 21

Release Status: release


Description:

   `declare -f` wrongly displays the `coproc my_command` statement.

   It adds the word COPROC after the `coproc` word. I use some kind

   of RPC in my scripts, so after several passes of the function,

   the line becomes: `coproc COPROC COPROC ... COPROC my_command`


Repeat-By:

   # define a function:

   process() {

   coproc inotifywait -qm /home

   read -u ${COPROC[0]} event

   }

   # display it

   declare -f process

   process ()

   {

   coproc COPROC inotifywait -qm /home;

   read -u ${COPROC[0]} event

   }

   # iterate 2 times (just to test):

 source <(declare -f process)

 source <(declare -f process)

   declare -f process

   process ()

   {

   coproc COPROC COPROC COPROC inotifywait -qm /home;

   read -u ${COPROC[0]} event

   }


Fix:

   # use curly braces:

   process() {

   coproc { inotifywait -qm /home; }

   read -u ${COPROC[0]} event

   }

   # in this case the word COPROC is added only once and further

   # calls does not change it, so the function works as expected.
   # But the drawback in this approach is that more processes are
created.
   # It can be seen in pstree:
   test───test───inotifywait
   # In comparison with plain `coproc`:
   test───inotifywait

Re: Make reverse-i-search failure joltingly clear

[Chet Ramey]

On 12/11/23 2:09 AM, Dan Jacobson wrote:

Type ^R and some string,
At the point while we are typing that the search fails, all that
happens is the word "failed" gets added at front,


No, readline rings the bell as well. If you want it to use a visible bell
instead, change the value of the readline `bell-style' variable.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: bash encountered a coredump issue with stepping on memory

[Chet Ramey]

On 12/11/23 6:20 AM, wang yuhang wrote:

Is this at the same point as the core dump in your previous message?


yes


OK, then I would recommend building an asan-enabled version of bash and
seeing what it tells you.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Greg Wooledge]

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
.

No offense to Pierre; this really is the best we've got.  It's just sad
that the best answer looks like *this*.

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

[Steffen Nurpmeso]

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

  https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00065.html

and especially

  https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00073.html

(which quotes)

  The 0x (or 0X) prefix in base 16 is optional so only skip over the
  prefix if the character following it is a valid hex char.  The C99
  standard is clear that given the string "0xy" zero should be returned
  and endptr set to point to the "x"

though my "advise" is shows my bash geek status is much weaker
compared to what Greg Wooledge posted, referring to a much earlier
discussion that i was unaware of.

Sadly i keep

  jobs_selection ()
  {
  local j= a=${AWK:-awk};
  [ $# -gt 0 ] && j='&& $2 !~ /(^| )('$(echo "$@" | tr ' ' '|')')( |$)/';
  j=$(jobs -l | $a -F '[][]' '/^[[]/'"$j"'{print "%" $2}{next}');
  echo $j
  }

  $ alias j-
  alias j-='jobs_selection'

for "kill $(j-)" around.

--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)
|
| Only in December: lightful Dubai COP28 Narendra Modi quote:
|  A small part of humanity has ruthlessly exploited nature.
|  But the entire humanity is bearing the cost of it,
|  especially the inhabitants of the Global South.
|  The selfishness of a few will lead the world into darkness,
|  not just for themselves but for the entire world.
|  [Christians might think of Revelation 11:18
|The nations were angry, and your wrath has come[.]
|[.]for destroying those who destroy the earth.
|   But i find the above more kind, and much friendlier]

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

[Chet Ramey]

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

   https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00065.html

and especially

   https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00073.html


I try to give the message at the head of the thread where possible. Those
are two messages that directly discuss hex constants, you're right
about that.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Zachary Santer]

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 and now
they don't" is the issue they're trying to avoid, at least within a
release.

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

[Chet Ramey]

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 Red Hat people, "my scripts used to work and now
they don't" is the issue they're trying to avoid, at least within a
release.


Sure, I understand that. The part I was addressing was the "eternal
validity" of every bash release. If vendors are going to keep shipping
old versions of bash, it doesn't matter whether or not they are
declared EOL. That doesn't have any meaning. I don't release patches
for anything but the current version except in extraordinary
circumstances (shellshock was the only time, and I went back 8 releases
for that), so what does EOL mean?

On the other hand, they rarely pick up more than the most serious bug
fixes from subsequent versions, and most of the time not even those.

It does mean that people invest energy in devising ways to make scripts
run on varying versions of bash whose release dates span over ten years,
and become very angry when they run into problems with that.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: `declare -f` incorrectly displays `coproc` statement

[Chet Ramey]

On 12/11/23 9:41 AM, Albert Akchurin wrote:


Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2 
Patch Level: 21





Description:

`declare -f` wrongly displays the `coproc my_command` statement.


Thanks for the report. I agree that command printing should omit the
coproc name if the command is a simple command. The documentation warns
against using simple commands as coprocs, but the parser doesn't actually
prohibit it, and adding the coproc name there introduces ambiguity.

--
``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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Martin D Kealey]

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 above)
> and the consensus among those who participated was that it was a good
> thing to prevent base# without any digits from silently being treated
> as 0.


The wrap-up at the end of that discussion was this:

> *I'm not sure how relevant that language is to integer constants in
> expressions. I could also note that the language describing the base#n
> syntax only talks about digits, letters, `@', and `_'. The bash definition
> of arithmetic evaluation is taken from C. That includes integer constants,
> and, while the base#value syntax clearly extends the C definition of a
> constant, the `-' (and `+', FWIW) is still an operator as defined by C.*


One could be forgiven for taking that to mean "this is behaving as expected
and won't be changed".

Do you think there would have been more discussion in different
> circumstances?


That entire discussion was between 4 people, and started and finished in
less than a week.
Anyone who happened not to be around would have missed it, including me.

Can a consensus among 4 people really be fair and representative of
millions of Bash users?

Would you have participated, considering there's no sign of you on the
> bug-bash list between 2016 and 2020?
>

When the instructions say "send bug reports to X-bugs", it's natural to
assume that the primary audience for X-bugs is the people who fix bugs, and
other people should stay away. So for a long time I didn't join this list
because I wasn't in a position to contribute as a fixer.

Of course, that's not the only reason why people don't participate:
sometimes real life gets in the way and we don't have time to participate,
sometimes for weeks on end.

But yes, I would have participated had I known this discussion was going on.

In most projects this lack of discussion wouldn't matter: after the
discussion comes a proposed code change, and then code review, and then
even after release, it's an "experimental feature that may be retracted".

When we don't have those extra steps, and every release of bash is
"forever", yes, we need more considered discussion up front.

-Martin

PS: When I said "change the definition of a token", I meant specifically
changing the definition of the integer constant token, to require at least
one "digit" after the '#'.

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

[Koichi Murase]

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 $((10#-digits)) but not
> > $((10#))).
>
> I'm not a big fan of `10#[-+]digits' and invalidating `10#' either
> since the Bash change also broke mine [1,2], but I'd say the above
> lookahead switching is worse than the current behavior. [...]

I checked the behaviors of different shells because I was interested
in them.  They seem to vary more than I expected.

  | $((10#)) | $((2*10#-1)) | $((2*10#- 1))
--|--|--|---
bash-5.0  | 0| -1   | -1
bash-5.1  | error| error| error
ksh93u| 0| -2   | -1
ksh93v| error| error| error
mksh  | 0| -1   | -1
zsh   | 0| -2   | error

ksh93u is tested with "Version AJM 93u+m/1.0.3 2022-08-25" and
"Version AJM 93u+ 2012-08-01". ksh93v is tested with "Version A
2020.0.0" (strictly speaking, this is not 93v but developed based on
93v).  $((2*10# -1)) was the same as $((2*10#-1)). $((2*10# - 1)) was
the same as $((2*10#- 1)).

bash-5.0 behaves in the same way as mksh. bash-5.1 behaves in the same
way as ksh93v. ksh93u and zsh behave in a similar way, but zsh
produces a syntax error with `10#- 1'.  I think the behavior of zsh is
similar to the lookahead switching suggested by Martin.  ksh93u also
performs a kind of lookahead switching, but it's different from what
Martin suggests.

I guess bash-5.1 referenced the behavior of ksh93v, but this is
actually not an actively maintained branch.  Recently, ksh under an
active development seems to be ksh93u+m derived from ksh93u+.

--
Koichi