Live data from Hacker News

Atuin replaces your existing shell history with a SQLite database

github.com

21–30 of 198 posts

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

#21
post #7

But at what cost?

What kind of cost? Obviously, backups on the author's server are not something I'd ever do, but the "offline only mode" is there, apparently. TBH I was thinking about doing this for a while now. History of my shell, which now is 3.8MB in size, is one of my competitive advantages as a developer (and a very nice thing to have as a power user). It accumulated steadily since ~2005, and with fzf searching the history is m…

One such cost could be database size. I currently have 45k history entries in my database and it sits at roughly 15MB in size due to database indices along with the additional data we store

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

#22

I made a script that uses atuin to get previous commands related to your current command line - latest commands ran in the same session, in the same directory, in other sessions, latest commands for the same executable etc. then feeds it into GPT and streams the replies to fzf so you can choose the best autocompletion (or it can fix problems in the line you've written already as well). On Wezterm and Kitty it can als…

That sounds awesome! We've been meaning to set up a "community showcase" section. I'd love to feature this! If you ever publish it, post a discussion!

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

#24

This is the feature I've been looking for: "log exit code, cwd, hostname, session, command duration, etc"

There's a PR opened (that I still need to review...) that adds even more fields such as shell type and opt-in environment variables to this list.

One day, you could search for that AWS cli command run specifically on AWS_ACCOUNT_ID=foo

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

#25
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.

With atuin, it's available immediately on other local session (panes, windows, tabs etc). There's also remote sync, so after some configurable amount of time, it's even available on other devices.

Spectacular, thanks!

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

#26

Earlier quoted context omitted.

It's FOSS, with optional free service to host your history (encrypted with local key), I think there's a paid option above a free tier You can also host your own backend

There's currently no paid option. Obviously one should assume such a free service can't be sustainable so you'd be correct to think we should have one. Currently we rely on Github sponsors as well as our own additional funding

With the server, is it primarily a gateway to the hosted SQLite databases?

eg receives incoming shell history to store in the backend, and maybe do some searches/retrievals of shell history to pass back? eg for shell completion, etc

If that's the case, then I'm wondering if it could work in with online data stores (eg https://api.dbhub.io <-- my project) that do remote SQLite storage, remote querying, etc.

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

#27
post #8

But at what cost?

there's this little gotcha you might want to be aware of: https://github.com/ellie/atuin/issues/752#issuecomment-14518...

It sounds serious, but there's not much info in that issue of what's going wrong, why it's going wrong, etc. (?)

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

#28

Earlier quoted context omitted.

There's currently no paid option. Obviously one should assume such a free service can't be sustainable so you'd be correct to think we should have one. Currently we rely on Github sponsors as well as our own additional funding

With the server, is it primarily a gateway to the hosted SQLite databases? eg receives incoming shell history to store in the backend, and maybe do some searches/retrievals of shell history to pass back? eg for shell completion, etc If that's the case, then I'm wondering if it could work in with online data stores (eg https://api.dbhub.io <-- my project) that do remote SQLite storage, remote querying, etc.

We currently use postgres. The server is very dumb, verifies user authentication and allows paging through the encrypted entries.

There's a PoC that allows it to work with SQLite too for single user setups - and we are thinking of switching to a distributed object store for our public server since we don't need any relational behaviour.

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

#29

This is the feature I've been looking for: "log exit code, cwd, hostname, session, command duration, etc"

you can mostly do that in bash:

    export PROMPT_COMMAND='if [ "$(id -u)" -ne 0 ]; then echo "$(date "+%Y-%m-%d.%H:%M:%S") $(pwd) $(history 1)" >> ~/stuff/logs/bash-history-$(date "+%Y-%m-%d").log; fi'
makes files like

    stuff/logs/bash-history-2023-05-06.log
that contain

    2023-05-06.11:42:38 /home/dv  3737  2023-05-06 11:42:38 cat .bashrc
then you can make some commands to grep through this

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

#30
post #7

Earlier quoted context omitted.

What kind of cost? Obviously, backups on the author's server are not something I'd ever do, but the "offline only mode" is there, apparently. TBH I was thinking about doing this for a while now. History of my shell, which now is 3.8MB in size, is one of my competitive advantages as a developer (and a very nice thing to have as a power user). It accumulated steadily since ~2005, and with fzf searching the history is m…

One such cost could be database size. I currently have 45k history entries in my database and it sits at roughly 15MB in size due to database indices along with the additional data we store

But it's a cost shared by all open shells, right? Well, even if it was 15MB per shell session, it should still be worth it if the startup and searching is faster.

For comparison: I use extended ZSH history format, which records a timestamp and duration of the call (and nothing else), and I have ~65k entries there, with history file size, as mentioned, 3.8MB. It could be an order of magnitude larger and I still wouldn't care, as long as it loads faster than it takes ZSH to parse its history file.

Post reply on HN