_ble_builtin_trap_n2i: bad array subscript

[0xC0ncord]

ble version: 0.4.0-devel3+0f01cab Bash version: 4.2.46(2)-release, x86_64-redhat-linux-gnu

Whenever I run any command, the trap catcher raises the error bash: _ble_builtin_trap_n2i: bad array subscript twice, i.e.:

$ echo test
bash: _ble_builtin_trap_n2i: bad array subscript
bash: _ble_builtin_trap_n2i: bad array subscript
test
$

I have reproduced this on the latest devel version as well, but I am getting other major problems with it on this bash version that I have not yet figured out.

[akinomyoga]

Thank you for the report! OK, I could reproduce it. It seems to happen when ble.sh is loaded in a function in Bash 4.2. It doesn't happen in the other versions of Bash. I'll take a look at what is happening here.

[akinomyoga]

This is caused by a bug of Bash 4.2.

$ bash-4.2 -c 'a(){ declare -gA d=([k]=v);};a;declare -p d'
declare -A d='()'
$ bash-4.3 -c 'a(){ declare -gA d=([k]=v);};a;declare -p d'
declare -A d='([k]="v" )'

It was fixed in bash-4.3. I found the following item In CHANGES of bash.

------------------------------------------------------------------------------
This document details the changes between this version, bash-4.3-alpha,
and the previous version, bash-4.2-release.

1.  Changes to Bash

[...]

ddd. Fixed several bugs that caused `declare -g' to not set the right global
     variables or to misbehave when declaring global indexed arrays.

[...]

So, I decided to use a fallback implementation for Bash 4.2 when ble.sh is sourced in a function. I pushed a fix to master branch (8856a04). Could you check everything works fine now?

By the way, although I believe it now works without the error of "bad array subscript", I recommend you to either source ble.sh at the top level of .bashrc or use Bash 4.3+.

[0xC0ncord]

Unless I am doing something wrong (I ran ble-update and re-sourced ble.sh in a new shell), I am getting bash: @NUL: syntax error: operand expected (error token is "@NUL") as soon as ble.sh is sourced.

I recommend you to either source ble.sh at the top level of .bashrc

Everything works OK if I do this though.

[0xC0ncord]

This is how I am sourcing ble.sh normally: https://github.com/0xC0ncord/dotfiles/blob/master/.bashrc.d/11-blesh.sh This file gets sourced by .bashrc at the root level, and the functions get called. Can you think of any other way that I can keep this functionality on Bash 4.2?

[akinomyoga]

Thank you for testing!

I am getting bash: @NUL: syntax error: operand expected (error token is "@NUL") as soon as ble.sh is sourced.

Hmm... it doesn't reproduce at my side. My Bash 4.2 is version 4.2.53(2), so I have checked Bash-4.2 patches 47..53, but I couldn't find anything relevant. I'm not sure whether it is related, but I added another fix (3cae6e4). Could you try it again?

Can you think of any other way that I can keep this functionality on Bash 4.2?

Actually, it should work. In fact, sourcing ble.sh in a function works in my environment with Bash 4.2.53. If there are problems, I think I can fix them if you could provide sufficient information.

Thank you!

[0xC0ncord]

I can reliably reproduce the @NUL error specifically by calling ble-attach. Sourcing ble.sh without --noattach works, and calling ((_ble_bash)) works (when using --noattach). Hopefully this provides some useful information. I have updated to master again and am still getting this problem.

I noticed that after this error, anything I type is not visible, but I can still enter commands. If I do reset, I see these messages:

Erase set to delete.
Kill set to control-U (^U).
Interrupt set to control-C (^C).
$

Also, I can source ble.sh with --noattach and run ble-attach without problems if I skip ((_ble_bash)).

[0xC0ncord]

I can reliably reproduce the @NUL error specifically by calling ble-attach. Sourcing ble.sh without --noattach works, and calling ((_ble_bash)) works (when using --noattach).

I have to clarify: I found that this is the case when doing this interactively on the commandline (not in .bashrc). From .bashrc, both ble-attach and sourcing without --noattach gives this problem.

[akinomyoga]

Hmm, not sure but can you try to remove the following internal cache files?

$ rm "$_ble_base_cache"/cmap+*.dump

[0xC0ncord]

Hmm, not sure but can you try to remove the following internal cache files?

$ rm "$_ble_base_cache"/cmap+*.dump

Looks like that fixed it! Thank you so much!

[0xC0ncord]

Closing this, as the original issue has been resolved.

[akinomyoga]

OK! Thank you!