The problem I see is that if I ssh into 5 different remote hosts in a day, most of the commands are not executed on my host and thus not part of the local (or shared, distributed) history. I suppose this could be solved with either: - Some kind of modified ssh that sends back the commands to my host - Some kind of smart terminal that can analyze commands to build up the history Any ideas on how to practically solve t…
You could install atuin on all your remote hosts, but that's not always practical
Atuin replaces your existing shell history with a SQLite database
91–100 of 198 posts
Re: Atuin replaces your existing shell history with a SQLite database
#92I found atuin introduced friction where there wasn't any before, so I stopped using it and reverted to ripgrepping zsh_history.
Do you remember what that friction point was?
In fzf, there is no noticeable lag when typing.
Re: Atuin replaces your existing shell history with a SQLite database
#93I stopped using Atuin because you need one additional click to go up the history, and the configuration didn't provide an easy way to change that behavior. Edit: apparently, they made it possible to disable that behavior and the documentation is much better
Re: Atuin replaces your existing shell history with a SQLite database
#94> English | 简体中文 > You may use either the server I host Right. And isn't this what home dirs are for?
Yeah you could totally sync your shell history if you’re using a NFS share or something, but that’s going to affect way more than just your .bash_history Why is our localisation relevant/quoted?
Re: Atuin replaces your existing shell history with a SQLite database
#95Earlier quoted context omitted.
At 0.5GB that's 5k per entry -- what are you storing for each? For comparison, my (non-work) history since 2012 (plain text) is 181k entries, and takes 25MB. I store the command along with when and where you ran it. ( https://www.jefftk.com/p/logging-shell-history-in-zsh )
Not the op, but I'd guess it's the full text search index.
Re: Atuin replaces your existing shell history with a SQLite database
#96What's it like with many shells/panes in multiplexers open? I often find my history from one or another either lost or not available across different ones.
# append to .bash_history and reread after each command
export PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
# append to .bash_history instead of overwriting
shopt -s histappendRe: Atuin replaces your existing shell history with a SQLite database
#97It looks interesting, so if I'm overlooking a way to do this with fish, I'd experiment with it.
Re: Atuin replaces your existing shell history with a SQLite database
#98Earlier quoted context omitted.
Why put effort into removing them? They use a trivial amount of disk space.
Disk space is the least of the problems garbage entries in command history cause. It's not just commands that are actual for the current session (like ls/cd/cat), it's also incorrect commands or just commands not worth retaining still being saved among with the useful commands. The most precious is user's time. And when you fzf part of the command with the regularly saved history and would like to re-execute somethin…
Also, when I do want to reference my deep history I often find that seeing the full list of what I was doing is helpful at getting myself back into the frame of mind I was in when I ran the commands originally, which can be more valuable than seeing exactly which commands I ran.
Re: Atuin replaces your existing shell history with a SQLite database
#99 ls | grep | less
vs ls ~ | grep .bak | less
ls .config | grep *rc | less
you get the idea