Issues and logging with Bash?

Help
1

Hi,

First, thanks for the great tool! I am having a couple of issues and am unable to troubleshoot effectively, so just thought I would post some general queries before more github issues.

  • Not all commands being logged? i.e. I type a command, run it, then press (up). I would expect the last command to be the first in the list, even if it matches a prior one, with the local DB updated.

  • No external log output? In debugging the above, I would hope there would be a mechanism to inspect debug logs of Atuin’s execution and server communication, but there doesn’t seem to be a mechanism for this.

Thanks again, would appreciate any insights.

Environment:
Fedora rawhide, Bash 5.2 (with bash_preexec), Self-hosted server.

config.toml:

sync_address = "https://atuin.<myserver>.com"
show_preview = true
enter_accept = true
return_query = true

.bashrc:

[ -f ~/.local/bin/bash-preexec.sh ] && source ~/.bash-preexec.sh
eval "$(atuin init bash)"
2

What behavior are you observing?

3

A bit variable, but essentially opening a terminal, running a command (eg ls), then pressing up I would expect to see that command first in the list, but am in fact seeing commands I ran several minutes or hours ago. Often the command I enter is not even being saved, ie it does not appear when I re-enter it in the search box.

4

If you are able, I’d really appreciate if you could confirm if this also happens for you on v17.2.1?

5

Thanks, have rolled my laptop back to 17.2.1 and will test.

6

Yes unfortunately same behaviour with 17.2.1.

7

Sorry for the back-and-forth, but does it still occur in the latest weekly?

We had a bash-related fix land, so I suspect that will sort it for you

8

Thanks, unfortunately still not quite working with 18.0.1. Particularly noticable if I use tab to load a prior command and edit it before running, the edited command is not stored.

9

Is that 18.0.1 or the weekly release that I linked?

I cannot replicate it on that, though it happens occasionally on 18.0.1

10 
ryan@firebert ~/$ cargo install --list
atuin v18.0.1 (https://github.com/atuinsh/atuin?tag=weekly#38dfaabf):
    atuin

Still seeing it unfortunately, I opened a new terminal, ran the above, then hit up-arrow on the following empty line and the cargo install --list command was not (as I would expect but please correct me if I am wrong) listed as the most recent one.

11

I can confirm I’m experiencing a similar issue - it’s inconsistent.

My system is TrueNAS SCALE, so basically dabian bookworm.
I’m running bash within zellij - I’ll try without zellij, and see if that might be the cause.
Usually connect via Windows Terminal from a Windows machine on the LAN.
Results are inconsistent, I never know what to expect.

12

Here’s a patched version of preexec. You can either use the patched version or switch to ble.sh. Unfortunately bash still needs either one of these 2 prereqs.

I wasn’t able to attach it here, so here’s a link to the patched version of bash-preexec.sh.

I am using bash myself and I was close to switching shells…

13

Thanks! That modified version works a treat, have installed on my desktop and laptop and so far so good. Was hoping to avoid ble.sh to continue using Atuin.

14

To be fair, I have to mention that this preexec version has 2 patches:

The first one was written by the dev of ble.sh (akinomyoga) and the second one also had a few changes that included input from the same.

I agree that ble is a bit heavy and I use it with a minimal config. There are a few things that seem strange at first, (e.g. when you write a while loop with sleep and press ctrl-c you get a weird message), but it is quite powerful. Since starship, atuin and other utils require quite some time to initialize, using ble.sh doesn’t really make the login time much worse as it already is anyway…

However, this preexec version seems to work quite nicely as well.

1 Like
15

That’s been an intentional message, but I think it is not so useful to users. I added an option and disabled it by default in commit cebea478.

I think the patched version works well, but there are still minor cases where bash-preexec fails. A function definition will not be recorded. The comments will not be recorded too including the ones added by M-#. Maybe there are some other minor cases that I do not recognize.

2 Likes
16

Looks like the first patch @tessus listed has been merged to preexec, so it seems that updating preexec will help.

I’m also going to release v18.0.2 with the last bash fix from @akinomyoga, which will hopefully get us into a bit of a better state.

1 Like