This report is based on an observation made within the depths of this thread:
https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00094.html.
Attempting to assign an array to any of the following variables with the
declare builtin causes bash to immediately exit with no diagnostic message
be
On 6/27/23 6:47 PM, Grisha Levit wrote:
If SIGINT is received during the execution of a bind -x command, the
memory allocated for the saved parser state is leaked and the READLINE_*
variables remain in the environment
Thanks for the report and fix.
Chet
--
``The lyf so short, the craft so lon
On 28/06/2023 14:45, Kerin Millar wrote:
On Wed, 28 Jun 2023 12:42:16 +0200
Fabien Orjollet wrote:
On 28/06/2023 00:40, Kerin Millar wrote:
On Tue, 27 Jun 2023 21:52:53 +0200
of1 wrote:
On 27/06/2023 21:05, Kerin Millar wrote:
It doesn't work at all for >=5.2. The reason for this is inter
On Wed, 28 Jun 2023 12:42:16 +0200
Fabien Orjollet wrote:
> On 28/06/2023 00:40, Kerin Millar wrote:
> > On Tue, 27 Jun 2023 21:52:53 +0200
> > of1 wrote:
> >
> >> On 27/06/2023 21:05, Kerin Millar wrote:
> >>> It doesn't work at all for >=5.2. The reason for this is interesting and
> >>> I ma
On 28/06/2023 12:42, Fabien Orjollet wrote:
But by adding set -p to the subshell:
Well, works as well by adding :
so I'm not sure at all about set -p
time for i in {1..100}; do
#declare-P "$(set -p; declare -p)"
declare-P "$(:; declare -p)"
done
1>4648 2>5001 3>5001 4>5001 5>5000 6>5
On 28/06/2023 00:40, Kerin Millar wrote:
On Tue, 27 Jun 2023 21:52:53 +0200
of1 wrote:
On 27/06/2023 21:05, Kerin Millar wrote:
It doesn't work at all for >=5.2. The reason for this is interesting and I may
make a separate post about it.
Prior to 5.2, it can easily be tricked into printing
