Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subprocess commands missing from history #1847

Open
tjarvstrand opened this issue Mar 10, 2024 · 8 comments
Open

Subprocess commands missing from history #1847

tjarvstrand opened this issue Mar 10, 2024 · 8 comments

Comments

@tjarvstrand
Copy link

Hi,

First, thanks for a great tool! It's been a joy to use so far.

I routinely do eg. (cd x; mycommand) when I only want to run one or two commands inside a directory and I've noticed that these don't end up in the history. Is there any way I can get them to do that?

@arcuru
Copy link
Sponsor Contributor

arcuru commented Mar 10, 2024

Interesting, they show up for me using either bash or zsh. What's your environment like?

Note that the whole command is what will be in history, (cd x; mycommand), and the logged directory will be where you ran that command. I'm not sure if you're asking about mycommand itself not showing up.

@tjarvstrand
Copy link
Author

Yeah, (cd x; mycommand) is what I would like to be in the history :)

I'm on bash 5.2.15 on MacOS Ventura.

I do get the commands in the history, i.e. I can use the up arrow to run the command, but when I hit ctrl-r, they don't appear in that list.

@kenjo
Copy link

kenjo commented Mar 21, 2024

don't show up for me
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

there also is a problem if I use c-x c-e. I do have
shopt -s lithist
but removing that has the same result

using c-p I get the correct history in the built in list.

@mjf
Copy link

mjf commented Apr 4, 2024

Same here, e.g., (true) does not end up in atuin's history

atuin:
  version: 18.1.0
  sync: null
shell:
  name: bash
  plugins:
  - atuin
  - bash-preexec
system:
  os: Fedora Linux
  arch: x86_64
  version: '38'

To be honest, I haven't seen the atuin source code, but I'm very curious why there are all sort of such weird "missing in history" issues. Do you do some "parsing" or whatever on history commands? If so, could you explain why? And if so, is there a chance we can have our history intact (optionally, of course, some may not like it), matching exactly what's in our shell history? Thanks.

@frasty
Copy link

frasty commented Apr 8, 2024

Same here, e.g., (true) does not end up in atuin's history

atuin:
  version: 18.1.0
  sync: null
shell:
  name: bash
  plugins:
  - atuin
  - bash-preexec
system:
  os: Fedora Linux
  arch: x86_64
  version: '38'

To be honest, I haven't seen the atuin source code, but I'm very curious why there are all sort of such weird "missing in history" issues. Do you do some "parsing" or whatever on history commands? If so, could you explain why? And if so, is there a chance we can have our history intact (optionally, of course, some may not like it), matching exactly what's in our shell history? Thanks.

I definitely second this. Sometimes I am unwilling to search history through atuin because I know that some commands could be missed from history. I'd rather prefer to have my history intact even if that could lead to some privacy issues.

@akinomyoga
Copy link
Contributor

why there are all sort of such weird "missing in history" issues.

@mjf @frasty Those are all the limitations of bash-preexec, which Atuin uses to hook into the command execution of Bash.

Do you do some "parsing" or whatever on history commands?

No. Atuin maintains a separate command history, which is independent of the command history of Bash. When Atuin shows the search menu, it doesn't access the command history of Bash.

is there a chance we can have our history intact (optionally, of course, some may not like it), matching exactly what's in our shell history?

Have you noticed the Bash section in README? Currently, ble.sh is the only option if you want to record all the commands by Atuin. I think those descriptions are easy to miss, so I submitted a PR #1937.

@ellie
Copy link
Member

ellie commented Apr 9, 2024

In addition, there are no such errors with zsh/fish/xonsh/nushell. This is purely because Bash provides absolutely no way for us to hook into the shell lifecycle.

Bash preexec mostly just hacks the prompt. It works well enough, but there are some issues - as you've noted.

@akinomyoga's ble.sh is a reimplementation of the line editor in Bash, so has far more control and works better. We cannot install this by default however, as it does much more than just add some shell hooks

You'll probably find that a bunch of other shell plugins don't function quite so well with Bash

@mjf
Copy link

mjf commented Apr 9, 2024

why there are all sort of such weird "missing in history" issues.

@mjf @frasty Those are all the limitations of bash-preexec, which Atuin uses to hook into the command execution of Bash.

Yeah, I understand what you mean. But, see later on...

Do you do some "parsing" or whatever on history commands?

No. Atuin maintains a separate command history, which is independent of the command history of Bash. When Atuin shows the search menu, it doesn't access the command history of Bash.

Well, that's expected (and sorry for the poorly expressed sentence). To clarify it more further... I would like atuin to simply mirror what's in the Bash history. In my case, I even have some "hacks" in my Bash configuration, abusing for example the PROMPT_COMMAND to have history accessible immediately after opening another terminal while other is still opened (using buildin history -a|-c|-r for it). This may be no longer the issue if I used atuin to feed my history on Bash startup and let me do something similar, like any command I use to get the last Bash history record | atuin history put [--context <context>] whenever I want or something alike (i.e. to "feed" atuin with anything I would like to see in it's history right on). I tried the atuin history start|end btw., but without much success because, obviously, both the commands goes to the Bash history now while I am using the bash-preexec... 😀

Sidenote: My idea is to feed history entries into atuin myself, anyhow I choose to do it, and I can then invoke it from my .inputrc without the need to install the ugly Bash hacks. And I should be free to use it also in other cases (how splendid it would be if I could use it for any other libinput-enabled tools). The last idea involves that atuin would have to adapt some sort of custom/configurable "contexts" apart from the pre-defined "host", "global" etc.

is there a chance we can have our history intact (optionally, of course, some may not like it), matching exactly what's in our shell history?

Have you noticed the Bash section in README? Currently, ble.sh is the only option if you want to record all the commands by Atuin. I think those descriptions are easy to miss, so I submitted a PR #1937.

Great. But, to be honest, I would like to get rid of the additional Bash stuff in my setup. The simple atuin history put I suggest above, would likely solve it for my needs. Or, do I miss something here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants