bug: up arrow still bound with disable-up-arrow

[aslafy-z]

When using up arrow while executing a command that does not consume stdin, atuin starts up after the command ended even if it was started with disable-up-arrow.

Environment

• zsh 5.9 (x86_64-pc-linux-gnu)
• atuin 14.0.1

Reproduction steps

• eval "$(atuin init zsh --disable-up-arrow)"
• sleep 5
• within the 5 seconds, press the up arrow
• wait for the timer to finish
• atuin shows

Workaround

Use the manual binding (see https://github.com/ellie/atuin/blob/main/docs/docs/config/key-binding.md#zsh):

export ATUIN_NOBIND="true"
eval "$(atuin init zsh)"
bindkey '^r' _atuin_search_widget

[wisewtf]

Same thing happens to me. Seems like I cannot disable up arrow interactions. I'm using BASH.

[bob454522]

shoot- i was coming here hoping i could disable up arrow (for now, as im having issues w atuin messing up my terminal at times).

so for now i can offer what ive been doing (as a work around) to disable up arrow. you just manually add the output of atuin init bash to the bottom of your .bashrc , and then comment out the 2x bind commands at the bottom ( the ones for up arrow), reload your bash session and up arrow is no longer bound to atuin (but ctrl+r still is, if you like).

also dont forget to remove or comment out the initial eval "$(atuin init bash)"

as an example here is how the bottom of my .bashrc looks (for now, until atuin get the terminal mess up issue resolved)

[aslafy-z]

For the record, I updated OP with my current workaround.

[wisewtf]

shoot- i was coming here hoping i could disable up arrow (for now, as im having issues w atuin messing up my terminal at times).

so for now i can offer what ive been doing (as a work around) to disable up arrow. you just manually add the output of atuin init bash to the bottom of your .bashrc , and then comment out the 2x bind commands at the bottom ( the ones for up arrow), reload your bash session and up arrow is no longer bound to atuin (but ctrl+r still is, if you like).

also dont forget to remove or comment out the initial eval "$(atuin init bash)"

as an example here is how the bottom of my .bashrc looks (for now, until atuin get the terminal mess up issue resolved)

Thank you for this. Don't know why I didn't think of it sooner.

[salzig]

by comparing atuin init zsh and atuin init zsh --disable-up-arrow it looks like the keybinding for up-arrow is skipped as described by the option.

eval "$(atuin init zsh --disable-up-arrow)" in ~/.zshrc seems to work as expected for me. Thanks to this issue I now know about --disable-up-arrow :D

[DanielRivasMD]

I had the same issue on v16.0.0 using zsh. I had install atuin using antigen antigen bundle atuinsh/atuin. I remove that and use the recommend documentation export ATUIN_NOBIND="true"; eval "$(atuin init zsh)". Then it worked just fine.

[cameronj86]

The workaround worked for me using bash as well.

Did delete 1-2 existing atuin lines already on .bashrc that were referring to atuin init bash IIRC

[ellie]

I'm currently unable to replicate this on either zsh, or on bash

Can anyone who had the issue here confirm if it's still happening?

If so, I'd really appreciate you sharing your shell config file

[Jorrit05]

@ellie I still have this issue, version 18.0.2, on a MacBook using zsh. I've added this to the bottom of ~/.zshrc:

# eval "$(atuin init zsh --disable-up-arrow)" (tried this on it's own, did not work)
export ATUIN_NOBIND="true"
eval "$(atuin init zsh)"
bindkey '^r' _atuin_search_widget

But the up arrow is still bound.

[ellie]

@Jorrit05 can you share your entire zshrc please?

Also, please try reducing your zshrc to only what you have shown there, and confirm that the issue still occurs

[Jorrit05]

ah well, it works! But only after starting a completely new shell. source ~/.zshrc was not enough apparently. (with my full zshrc file, not just those 3 lines)

[ellie]

ah yes - sourcing does not clear all existing keybindings, only executes what's in your zshrc. So, the previous binding would still have been there

[aslafy-z]

I confirm, my steps (found in OP) cannot be reproduced anymore, this issue is now fixed! Thank you for your work on this project!