bash_execute_unix_command: cannot find keymap for command

[twiecki]

When I press the up-arrow-key I get bash_execute_unix_command: cannot find keymap for command. This is bash on OSX.

[conradludgate]

What version of bash are you running?

[twiecki]

GNU bash, version 3.2.57(1)-release (arm64-apple-darwin21)

[twiecki]

I upgraded to GNU bash, version 5.2.15(1)-release (aarch64-apple-darwin21.6.0) now but same error.

[footlose]

I'm having the same issue. on 4.2.46(2)-release (x86_64-redhat-linux-gnu)

[shenshouer]

the same issue on centos 7 Linux xxx 4.14.141-2.el7.x86_64 #1 SMP Tue Feb 15 15:56:56 CST 2022 x86_64 x86_64 x86_64 GNU/Linux

[orsenthil]

I notice this issue on Mac, when with the latest version of atuin

bash --version
GNU bash, version 5.1.16(1)-release (x86_64-apple-darwin20.6.0)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

-bash: bash_execute_unix_command: cannot find keymap for command

[njames]

I am also having this issue - I just reinstalled atuin and restarted the terminal

bash --version
GNU bash, version 5.2.15(1)-release (x86_64-apple-darwin22.1.0)

[njames]

I reread the documentation and made these adjustments

 export ATUIN_NOBIND="true"
 eval "$(atuin init bash)"

 # bind to ctrl-r, add any other bindings you want here too
  bind -x '"\C-r": __atuin_history'
  bind  '"\e[A":history-search-backward'
  bind  '"\e[B":history-search-forward'

removing the -x seemed to help but enter is not returning the selected command from the ctrl-r screen :(

[Subfire]

same issue on CentOS 7

[arcuru]

Resh has this issue as well and also hasn't resolved it: https://github.com/curusarn/resh/issues/157

[berceanu]

I have the same problem, with

GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

atuin 17.0.1

❯ bash --version
GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

❯ uname -a
Linux 3.10.0-1160.102.1.el7.x86_64 #1 SMP x86_64 x86_64 x86_64 GNU/Linux

[ryanwwest]

Having the same problem on macos with GNU bash, version 3.2.57(1)-release (arm64-apple-darwin21). I installed this and it worked well for a few days until maybe a reboot?, and since then just this error.

[turian]

I just installed atuin on OSX and got this too.

GNU bash, version 3.2.57(1)-release (arm64-apple-darwin23)

[akinomyoga]

This was just fixed in commit https://github.com/atuinsh/atuin/pull/1515/commits/b18f7acc52f57d557688f23a1c5036406e0525e5 in #1515 two days ago. It will be fixed in the next release. Anyway, you can instead install the latest version of Bash. The problem doesn't happen with bash >= 4.3. The 17-year-old Bash 3.2 has other issues, so it is generally recommended to install the latest version of Bash.

[berceanu]

That is not always possible, for example on HPC systems where the user does not have administrative privileges.

[akinomyoga]

Of course, it is not always possible. It's just generally recommended. I meant "usually" by the term "generally", and the recommendation is just a recommendation. Anyway, I think it's still worth considering.

If you are on an HPC system, you usually (not 100%) have more chances than on the other types of systems. We usually have compilers in HPC systems, so you can compile Bash from the source code and install it in your home directory. You can exec your local Bash in .bashrc with a version check on the currently running Bash. Sometimes, compilers on HPC systems produce strange binaries whose forking and threading ability is restricted so that the job scheduler can interfere with it. Even in such a case, you may try cross-compiling (with a matching library) in another host or generate a standalone binary with -static* options, and copy the generated binary to the HPC system. Or you should ask the administrator if it is possible to introduce a newer version of Bash (probably after some approval by some committee meeting, the head of the institution, etc.). It's still not 100 percent, but it's worth trying.

[atuin-bot]

This issue has been mentioned on Atuin Community. There might be relevant details there:

https://forum.atuin.sh/t/up-arrow-error-commands-not-saved/339/2

[jacktose]

Hi, it's me from that community post. Looking forward to the release of the newly patched version (#2060)! Details there, short version for the record:

I'm on bash 4.2.46(2)-release & CentOS 7. When I install & use bash 5.2.26(1)-release (from homebrew), the keybind problem goes away. (But I have unrelated complications and would rather not do that always.)

Probably unrelated, because I don't see anyone else mention it here: Atuin is also not saving my commands (in either bash version), despite bash-preexec being apparently installed & activated. 🤷