stinkpot: sqlite-backed shell history
32 points by op
32 points by op
I only realized how bloated Atuin had become this week, when I typed "?" at my prompt by mistake and it started asking me if I wanted to enable "AI mode". No thanks.
I've now switched to stinkpot, thanks for the share :)
I really love this project, I have faced the burn of losing shell commands and I have tried atuin.sh but I didn't really like it so much.
Also loving how this is 400 lines of go, people using golang to create static minimalist binaries while the code behind it is simplistic as well. Golang is an amazing language in general :)
I will try out stinkpot, it seems interesting!
What does sqlite give you here over things that read the history file directly like hstr or fzf? I have been using hstr for 15 or so years and lately I have been switching to fzf. I never understood the need for sqlite for this, however I am a big fan of sqlite in general.
it may be possible with plain fzf! if you get bash to flush shell history to the file after each command, you could get a similar experience with just plain fzf. the history file is unstructured by default, sqlite is able to store more structured data (exit code, time of exit etc.) but also able to do more advanced things on insert quickly (like deduplication, or modifying time-of-run when a command is run for the second time).
You guys should try fish shell. This feature is provided out of the box and works flawlessly even with multi line commands.
One use case I've had in mind is storing and indexing the cwd for every history entry. In theory you could (painstakingly) reconstruct this context from the history itself, but being able to quickly index shell history scoped to a project directory would be quite useful for me.
Definitely something to try. Atuin became a zoo of features that I barely care. From positive side it works (huge chance that I have not updated in a while…)
I've known Atuin for a while but I hadn't tried it until this week. At this rate I'm pretty sure it'll start reading emails soon.
almost all of the features in atuin are optional, so you can create a custom build with the feature flags off.
the sync server, dotfiles manager etc. are not optional however, so I did tinker with a fork of atuin: https://tangled.org/oppi.li/hatchling that removed all those features, and the resulting bin was ~3MB (as opposed to 30MB with all features enabled!).
ultimately the codebase was still quite large, so I chose to roll my own thing. the fuzzy search does not have the same quality as atuin but it works well enough!
sync server is optional and it's so optional that it's not included in default atuin binary anymore but built as a separate executable (https://github.com/atuinsh/atuin/pull/3112)
This is great, does it filter history by ’cwd’? That’s the only reason I use Atuin, for making the directory the anchor for my command history. I just cd into a project and pick up right where I left off. It’s particularly useful if I had to run some long commands with bunch of paramas.
while i personally don't prefer that behavior, it should be possible with a caveat: only commands run after stinkpot was installed register the cwd. bash_history by default does not include it.
You should add a license to your project if you want others to fearlessly use your code :)
If you don't mind (and add an open license) I'd kinda like to integrate it into my experimental oils readline. History is one of my topmost TODOs as soon as I get dynamic widgets figured out
I wonder how easy it would be to delete commands from one's history? Would it be diving into some sql to delete a row from the sqlite db? Odd as it might seem there are rare times, when I need to delete lines of commands from my shell history...The legacy approach lets me manually go into my bash history and manually delete the offending line...I know, i know, that's silly...but it is indeed a use-case for me. Has anyone who uses stinkpot know if there is a command do remove lines without divjng into sqlite DB manually?
EDIT: Sorry, i failed to state, that regardless of my odd use-case, the project seems really quite interesting! Thanks for making this and for sharing!