Atuin, bash, and ble.sh

Help
1

If ble.sh is not sourced, none of the commands I enter actually show up in atuin.

I am using bash 5.2.26. I seriously dislike what ble.sh is doing to my shell, because I have already customized the !@#$ out of my shell.
Additionally all of the key bindings for git and fzf stopped working (I also tried to rebind them again, after sourcing ble.sh).

Is there maybe a minimum setup of ble.sh that only makes atuin work without messing with my shell? The rc file is like 1300 lines long, thus I haven’t really looked into it yet, but maybe somebody has already figured something out.

I’d appreciate any help in this matter. Currently I can’t use atuin, because ble.sh destroys my setup.

2

You can also use bash-preexec

Please see the installation section of the docs: Installation | Atuin Docs

Bash does not provide the hooks we need to record history. Hence the requirement of one of these two.

3

Thanks for the quick reply. I only tried ble.sh, because it was mentioned that preexec had issues.

But it seems that this is the only option for me. At least for now. Thanks.

Maybe it is time to switch to zsh.
The only problem is that I’ve customized my shell over many, many years. Porting this to zsh will be a pain. :wink:

4

Not sure, if this is works as designed, but if I do

./atuin
and then
./atuin default-config

the second command does not show up in my history. But when I do ./atuin status, it shows up. But ./atuin default-config is nowhere to be found. Btw, ./atuin -V does not show up either.

I am not using any cwd_filter or history_filter.

Why is atuin not adding all commands to the history?

P.S.: I am also using https://github.com/magicmonty/bash-git-prompt.git

5

I did a bit more debugging and it seems that atuin + bash only work nicely, if there are no major mods to the shell.

Well, I guess it is time to rethink a bunch of the changes I did over the years. This gives me a good reason to streamline my config/setup.

6

Any way of getting bash hooks is going to be a hack and potentially clash with existing configuration I’m afraid.

Every other shell we support has native ways of

  1. Hooking into the shell lifecycle
  2. Working with the line editor

I hope someday bash supports this too

7

No worries, as I said, it gives me a reason to get rid of stuff that has nicer alternatives these days. I just haven’t done it until now because you know how it is: never change a running system.

But I can replace the bash-git-prompt functionality with starship and so on. Thus all good. Although it will me take a while to get the prompt I want with starship. Haha.

1 Like
8

Just out of curiosity, would you mind sharing with me what kind of keybindings you have? What are the arguments to the bind command? I try to make ble.sh work with any existing settings as much as possible, and it’s not my intention to destroy your setup. I think this is the first report saying no keybindings work. You don’t really have to use ble.sh, but I just would like to collect the information.

Now that you never use ble.sh, it may be irrelevant to you, but for the integration with fzf, you could check §2.8 in README. An additional adjustment is needed because of a hack used by fzf. For the minimum setup of ble.sh, you could check §2.2 in README.

Here are just random thinking.

I’m not sure if it is related, but openSUSE shipped with broken /etc/inputrc which caused issues in ble.sh, so ble.sh currently doesn’t try to parse the runtime keybindings of Readline in openSUSE but instead parses the user’s ~/.inputrc. Also, after ble-attach in ~/.bashrc (if any), builtin bind cannot be used; it will break the line editor. You need to use unprefixed bind.

Another possibility may be the conflict with the autosuggestion keybinding which overrides the keybinding of the base keymap. For example, C-g and C-f are handled by autosuggestion by default, so one needs to unbind them using ble-bind -m auto_complete -f C-g -, etc. to honor the keybinding in the base keymap.

9

I am either using Fedora/Debian/macOS. My setup is pretty much the same when it comes to bash.

I’m currently testing atuin on Fedora 39.

Unfortunately bash-preexec does not work either. I thought it did, but there is still a problem somewhere with atuin. commands are only randomly added to the atuin history and I can’t figure out what the issue is. I think I might need @ellie’s help to figure out the problem.

I already got rid of the bash-git-prompt, which I thought was the reason that atuin did not record all commands (and switched to starship). But apparently that was not it either.

(The following links will point to the entire files.)

At the end of my .bashrc I added the following lines:

[[ -f /usr/local/bin/bash-preexec.sh ]] && source /usr/local/bin/bash-preexec.sh
export STARSHIP_CONFIG=/etc/starship.toml
eval "$(starship init bash)"
eval "$(atuin init bash)"

My .bash_profile is rather basic, and I modified the /etc/bashrc to include a few aliases, completions, and keybindings:

[ -f /etc/bash_completion.d/fzf ] && . /etc/bash_completion.d/fzf
[ -f /usr/share/fzf/shell/key-bindings.bash ] && . /usr/share/fzf/shell/key-bindings.bash
[ -f /opt/completion/fzf_git.sh ] && . /opt/completion/fzf_git.sh

I even removed these 3 lines above for testing purposes, so that even fzf does not use any hooks, but atuin still does not add every command to the history. I just can’t figure out why that is.

For completeness I’ll link the following files as well:

/etc/bash_completion.d/fzf
/usr/share/fzf/shell/key-bindings.bash
/opt/completion/fzf_git.sh

The 3 files above won’t really help to debug the atuin problem, but @akinomyoga can see what my keybindings are. When replacing bash-preexec with ble.sh, and I do a Ctrl-g h in a repo dir, I don’t get a fzf window with all my commits. Or at least I don’t see it. I think it is there, because, if I press enter a few times it will return the first hash in the commit list. The window however will show up, when I call fzf_gh directly. Weird, but maybe it has something to what @akinomyoga described earlier. I will have to look into that. I just need a break to get my head clear again. :wink:

10

commands are only randomly added to the atuin history

That seems a common issue when used with bash-preexec, but somehow it doesn’t seem to happen in my environment with bash-preexec.

I’m also using Fedora mainly [Fedora Linux 39 (Server Edition)], so I tried your settings of .bash_profile & /etc/bashrc & ~/.bashrc, but the problem doesn’t seem to reproduce, though I’m not sure if something in your ~/.bashrc.d/* causes an issue in your environment.

Which version of bash-preexec do you use? If it’s not the latest version, maybe you can try the latest version of bash-preexec from rcaloras/bash-preexec.

11

Thank you for the information for ble.sh.

OK. Those are standard ones (plus you seem to have extended fzf-git.sh). I somehow misunderstood that you have separate settings for git in addition to the fzf settings. Then, all those settings are related to fzf, which was the reason that nothing worked. As mentioned above, fzf-related settings need adjustments.

If you still have the energy to look into that, you can simply use the integration settings provided by ble.sh instead of (directly) sourcing those three files. In your case, you can have a switch for the blesh’s integration in your /etc/bashrc.

if [[ ${BLE_VERSION-} ]]; then
  ble-import -d integration/fzf-completion
  ble-import -d integration/fzf-key-bindings
else
  [ -f /etc/bash_completion.d/fzf ] && . /etc/bash_completion.d/fzf
  [ -f /usr/share/fzf/shell/key-bindings.bash ] && . /usr/share/fzf/shell/key-bindings.bash
fi
[ -f /opt/completion/fzf_git.sh ] && . /opt/completion/fzf_git.sh

Please make sure to source ble.sh before sourcing /etc/bashrc in your ~/.bashrc so that BLE_VERSION is visible from /etc/bashrc when ble.sh is loaded.

If you wouldn’t have modified the fzf-git.sh of the upstream, you could similarly source the integrated version by ble-import -d integration/fzf-git. However, you seem to have your own settings in fzf_git.sh. You can instead adjust the binding part in your fzf_git.sh in the following way:

if [[ ${BLE_VERSION-} ]]; then
  function ble/widget/fzf-git {
    ble/widget/insert-string "$(fzf_$1)"
    ble/textarea#invalidate
  }
  ble-bind -f 'C-g C-f' 'fzf-git gf'
  ble-bind -f 'C-g C-b' 'fzf-git gb'
  ble-bind -f 'C-g C-t' 'fzf-git gt'
  ble-bind -f 'C-g C-h' 'fzf-git gh'
  ble-bind -f 'C-g C-r' 'fzf-git gr'
  ble-bind -f 'C-g C-l' 'fzf-git gl'
  ble-bind -m auto_complete -f 'C-g' -
else
  bind '"\er": redraw-current-line'
  bind '"\C-g\C-f": "$(fzf_gf)\e\C-e\er"'
  bind '"\C-g\C-b": "$(fzf_gb)\e\C-e\er"'
  bind '"\C-g\C-t": "$(fzf_gt)\e\C-e\er"'
  bind '"\C-g\C-h": "$(fzf_gh)\e\C-e\er"'
  bind '"\C-g\C-r": "$(fzf_gr)\e\C-e\er"'
  bind '"\C-g\C-l": "$(fzf_gl)\e\C-e\er"'
fi
1 Like
12

Thanks a bunch for your reply. I will test your changes to my integrations on the weekend.

Btw, even though I have bleopt exec_errexit_mark= sert in .blerc, I get this [ble: exit] message, when I disconnect from the box:

image
image1178×288 58.4 KB

But to be clear, I did not modify the fzf-git.sh. I’ve been using this for about 8 years. I found the original version a long time ago and changed it to my liking back then. I am certain this was not provided by the fzf dev. The fzf-git you are talking about has only been on junegunn’s repo for 2 years. :thinking: :wink:

13

That’s exec_exit_mark but not exec_errexit_mark. The config exec_errexit_mark is for the exit status of user commands. You need to specify an empty string to exec_exit_mark.

Actually, fzf-git.sh is the current name, and the original version didn’t have a name because it was provided here in the form of Gist. The original version was indeed provided by the fzf’s developer junegunn. It was just not in a normal GitHub repository. The Gist was continuously updated for these eight years and recently was migrated to a GitHub repository with a given name.

While testing, I actually took a diff of your fzf_git.sh with a certain point of the original version, and it has a large overlap so I’m sure that your fzf_git.sh is a variant of a certain point of the Gist, which I referred to with the current name, fzf-git.sh.

1 Like
14

GitHub #1003 (comment) seems to have identified the condition for the missing command, and I could reproduce it with the latest version of bash-preexec.

OK, I think this is caused because preexec is called for the Atuin’s keybinding. Hmm, bash-preexec doesn’t assume the setups where a command is run in keybindings.

1 Like
15

Ah, cool. Thanks. That one was not in the minimal setup you referenced in the README.

Hmm, that’s interesting. I am sure I did not get it from a gist. (I would have starred it for sure.) I’m also pretty sure I used it before 2018. No matter, I ripped it off somewhere and made a few changes… :wink:

I am not sure whether your fix will be merged or not. The reason why I prefer preexec is because it is easier to deploy (when not using ansible) and less heavy. And I don’t need anything but atuin to work.

I am certain that ble.sh is a wonderful line editor, it’s just that I don’t need it (except apparently for atuin to work.)

Thanks again. I will test your changes tomorrow.

16

I’ve tried running bash for a bit again, and it does seem like we’ve had a bit of a regression with history storing. preexec has always been a bit sketchy, but never quite this bad

17

It seems that the preexec project is dead. There’s been a fix available for the ignoreboth issue for 4 years, but has been totally ignored by the repo owner or the person who seems to have commit accesss.

Not sure what will happen to akinomyoga’s PR. Maybe you want to include a version of preexec that includes both patches in the atuin repo.

18

@akinomyoga has actually already had several PRs merged into that project in the past few weeks, so I’m pretty optimistic about that fix going in. There is likely other reasons for the ignoreboth fix not going in

Should the project be abandoned, we could consider patching it. I’d rather not become a maintainer for a bash-preexec fork, however.

19

:+1: however, his other PR has been open for about a year.

That is perfectly fine, but the maintainers should at least tell us or the creator of the PR why that is. :wink:

That I certainly do understand.

20

The fix is incomplete, there’s an alternative suggestion rcaloras/bash-preexec #119, and no concensus is formed which approach would be better.

I only submitted one (in addition to the present fix for bind -x commands) in the last few weeks. The others are older PRs. I’ve been little contributing to bash-preexec for about two years.

The bash-preexec project seems to require a third person to approve the PR. As far as I know, if there is an approval, the PR will be usually merged within a few days. (edit: To clarify, I’m not requesting both of you to approve the PR. You are a part of the second party, though it’s not obvious from the maintainer. I wouldn’t like such engineering. If you do so, you can include a disclaimer about the background)

For this reason, a complicated PR like rcaloras/bash-preexec #143 that is unlikely to get a review from third-party voluntary people is unlikely to be merged. I’m recently one of third-party reviewers, but I’m not fully convinced by both versions of ignoreboth workarounds so hesitate to approve either one.

However, the PR this time for bind -x commands is a simple and clear one, so it shouldn’t be hard to get a review and to be merged. If it is delayed more than a week, we may directly ask the maintainer to review it themselves.