Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atuin replaces your existing shell history with a SQLite database

github.com

Post reply on HN
Print view View original

101–110 of 198 posts

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

#101

Post by codetrotter »

chefandy wrote: post #79
bayesianbot wrote: post #16

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…

Does it incorporate the return code of the commands to get an approximate good/bad rating? I wonder what percentage of the CLI mistakes I make return zero anyway because it's a valid command that I simply misused.

For me one of the most common issues is when I write a regex but I have some of the escapes the wrong way around etc. So I’m giving a valid regex, but it’s not matching what I tried to match. And then I have to change it around a couple of times before it works.

One reason for this is that different programs have different rules for what should be escaped when, when you write a regex. For example, I think grep is a bit different from vim in this regard

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

#103

Post by tonymet »

Great idea I’d like to see more full text indexing of the home directory. Shell commands, configs, code files all deserve to be indexed.

Compared to Windows & MacOS – lack of cli and gui full text indexing is a real setback for linux/unix

apropos , locatedb and this are solid domain-specific attempts. Hopefully this expands to indexing a lot more content.

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

#104

Post by codetrotter »

maleldil wrote: post #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

If you just want to experiement with it for say a couple of weeks, does it really matter that the commands from those few weeks disappear if you decide not to continue using it?

Presumably you already have a long history of commands from past years in the original format. And if your command line usage is similar to mine, then most of the commands you will use in the future will be covered by your existing history.

So if a few weeks of experimenting with atuin ends with you deciding not to use atuin, then probably you will be fine going back to the old history files that do not include those weeks of activity.

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

#105

Post by doubled112 »

literalAardvark wrote: post #64
bayesianbot wrote: post #16

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, if somewhat overengineered. Though the idea of mistakenly putting credentials in the cli and it ending up in GPT is bothering me a bit.

Probably paranoia, but I’d be uncomfortable feeding it a bunch of domain and server names, along with any other more interesting params that might sneak in.

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

#106

Post by bastawhiz »

jefftk wrote: post #95
bastawhiz wrote: post #88

Earlier quoted context omitted.

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.

Grep only works if you want an exact string match. If you want to find words out of order or support features like stemming, fts is necessary.

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

#107

Post by samstave »

bayesianbot wrote: post #16

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…

>"...then feeds it into GPT..."

explain this please

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

#108

Post by wpietri »

bastawhiz wrote: post #106
jefftk wrote: post #95

Earlier quoted context omitted.

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

Grep only works if you want an exact string match. If you want to find words out of order or support features like stemming, fts is necessary.

Maybe I have some sort of disease, but while reading "find words out of order or support features like stemming" the regexs for that immediately flashed before my eyes, so I think "necessary" is a little strong there.

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

#110

Post by conradludgate »

shawabawa3 wrote: post #94
ellieh wrote: post #71

Earlier quoted context omitted.

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?

Well, all the client side code is open source and compilable, and all history is fully encrypted before being uploaded.

So even if we were being controlled, you still can be confident that we can't do anything with your data - all we can see is how active you are, that is until someone finds a way to quickly break xsalsa20poly1305.

Post reply on HN