Tracking `bash-preexec` issue

[LecrisUT]

Right now between bash-preexec and ble.sh, the former has less side-effects and it might be easier to package and ship, at least as the default dependency for the Fedora package. But the warning on the front-page raises questions. Is there any issue to be tracked either on atuin or bash-preexec about the failures mentioned?

[ellie]

It depends massively on the users setup, and how much they've configured their prompt/shell in general

bash-preexec is built on traps and PS1, in order to add shell hooks. It generally works fine so long as the user has an up-to-date bash, but there might be edge cases here and there. There isn't really much that can be done to workaround or improve this, as it is in essence a hack.

ble.sh provides full functionality as we'd expect, but totally replaces the line editor. We cannot and should not install that for users as the default, as it does so much more than they might expect

[LecrisUT]

Hmm, but at least you reckon a clean installation will not have unintended consequences?

And how obvious is it when they encounter a breakage? I myself have not encountered anything (or at least I don't know what I'm supposed to look out for), but I have a vanilla setup.

[akinomyoga]

a clean installation will not have unintended consequences? ... And how obvious is it when they encounter a breakage?

There are still minor problems even with clean installation when the user uses older versions of bash-preexec, which includes 0.5.0 you mentioned in rcaloras/bash-preexec#157. With bash-preexec before rcaloras/bash-preexec#152, the command duration will not be correctly measured after using Atuin's keybindings. I'm not sure if we can say that is an obvious breakage, but users report it as a problem.

The setup can be broken more easily with any other customizations. The problems are all related to the inherent limitations in the approach bash-preexec relies on. With older versions of bash-preexec, when the user has any custom keybindings to a shell command (with bind -x), commands can be missing in Atuin's history after using the keybindings. Even with the latest versions of bash-preexec, appending settings to PROMPT_COMMAND after the shell startup will break bash-preexec (see rcaloras/bash-preexec#143). You can look around at all the other issues and PRs in bash-preexec. Atuin can be affected by any of them.

With the latest bash-preexec on top of vanilla Bash, I cannot soon come up with an obvious breakage but cannot ensure that there is no problem as things are complicated with the bash-preexec approach.

[LecrisUT]

Thanks for the overview @akinomyoga. This is good because for downstream as long as we know what are the bugs that need to be fixed and tracked, we can apply the patches on top of the release, and poke upstream to cut releases more often.

[ellie]

I'm going to close this one - our install script and recommended install method use the bash-preexec master version, so we're not really affected by the lack of release there

Otherwise, the state of bash-preexec can be nicely summarized by their issue tracker

[MaxenceG2M]

[...] our install script and recommended install method use the bash-preexec [...]

Hi @ellie,

If I may ask a question on this old issue: the installer script use preexec, but the documentation seems to recommand using ble.sh. An improvement to installer to do?

Atuin works best in bash when using ble.sh.

If I'm in the wrong place I will open a new issue.
Thanks!

[akinomyoga]

I think we've agreed not to install ble.sh without the user's explicit consent, as ble.sh is much bigger than Atuin and the user may not be comfortable with changing everything just to install Atuin.

• Bash enter_accept best effort fixes #1384 (comment)
• fix(bash): improve the support for enter_accept with ble.sh #1465 (comment)

I think @ellie has also mentioned similar things several times in Discourse or Discord, but I don't remember the specific threads now.

A possible option may be to add an opt-in option in the installer to enable the ble.sh installation.

[MaxenceG2M]

That answers my question, thank you!

I just tried ble.sh by curiosity, and I understand why it's not installed by default - bring a lot of modifications in bash...

[LecrisUT]

That said we might be able to work something out on the distribution side. E.g. consider reading the options based on /etc/blesh -> /etc/blesh.d/* -> ~/blesh.d/*, with the right files running after the left ones. If the default setting (/etc/blesh) is an OOTB with all features enabled, then we could override it in /etc/blesh.d/atuin to be more minimal. For persistency, the current settings can be saved at first run in the home setup.