Live data from Hacker News

Atuin replaces your existing shell history with a SQLite database

github.com

91–100 of 198 posts

Re: Atuin replaces your existing shell history with a SQLite database

#91

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

I guess we need a PostgreSQL backend.

Re: Atuin replaces your existing shell history with a SQLite database

#92
post #53

I 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?

I'm not the parent commenter, but the friction point for me is the slowness when typing the first few characters in an interactive search (I have a large history). I think the searches are synchronous with each keystroke, right? It would feel a lot faster if each keystroke could cancel an in progress search instead of waiting for it to finish.

In fzf, there is no noticeable lag when typing.

Re: Atuin replaces your existing shell history with a SQLite database

#93

I 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

I use atuin to replace cmd+r history but not up arrow history, wasn't hard at all to configure

Re: Atuin replaces your existing shell history with a SQLite database

#94
post #71
post #69

> 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?

I think the implication is that you're controlled by the Chinese government because your software was translated to Chinese?

Re: Atuin replaces your existing shell history with a SQLite database

#95
post #59

Earlier 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.

For 100k entries you can grep them instantaneously; there's no need to maintain an index.

Re: Atuin replaces your existing shell history with a SQLite database

#96
post #6

What'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.

You can get that with bash with this config:

    # 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 histappend

Re: Atuin replaces your existing shell history with a SQLite database

#97
It looks like it's not possible to export the history to a format the shell can import[0], so if I wanted to try this out, my commands would be locked there.

It looks interesting, so if I'm overlooking a way to do this with fish, I'd experiment with it.

[0]: https://github.com/ellie/atuin/issues/816

Re: Atuin replaces your existing shell history with a SQLite database

#98
post #63

Earlier 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…

A typical command I run is never going to be something I look up again, so I would prefer to optimize for writing instead of reading. Dumping every command to a file adds no friction to my regular work, while attempting to categorize garbage commands would add a lot of friction.

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.

Post reply on HN