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

Stinkpot: SQLite-backed shell history

tangled.org

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Stinkpot: SQLite-backed shell history

#31

Post by shim__ »

icy wrote: post #20
shim__ wrote: post #14

Does it support just synching the db via nextcloud or similar? I'd prefer to stick to the Unix philosophy of one tool for one job instead of native cloud integration

I mean, it's an sqlite file on disk. You can sync it however you like. https://litestream.io is a fun choice.

Of course but my question was more in the direction of if the data is suitable to be transferred to another host without becoming useless. The native cloud integration could be attaching an origin field to each history field whereas the db itself might only be intended for local only use.

Re: Stinkpot: SQLite-backed shell history

#32

Post by fpoling »

OskarS wrote: post #16
fpoling wrote: post #13

Earlier quoted context omitted.

SQLite gives indexes that makes searching and locating previous entries much faster. This is relevant when the history is over 100K entries and one wants to avoid duplicates in history files.

I think you're underestimating the speed of modern computers and hard-drives, fzf can search through 100k entries easily without any delay. Try it with `cat /usr/share/dict/words | fzf`, it's extremely responsive (my dictionary is about 235k lines). If you want hard numbers, try piping your shell history through `time grep` and see how long finding an entry takes. Even if you're on spinning rust, your shell history i…

With SQLite one automatically gets reliable persistent storage. Try to emulate that with a text file with history that eliminates duplicates. It is surprisingly hard to archive.

Re: Stinkpot: SQLite-backed shell history

#34

Post by ptspts »

apodik wrote: post #8

is there a particular reason why i'd want sqlite-backed shell history? i mean sure it works but why not a text file? (which i'd assume is somewhat faster because you can just append) i guess you could say it's because you may want dates for each command but for that you can just use a CSV or TSV file no? does it have to do with the searching?

I have a regular Bash shell history with about 750 000 entries on an SSD on a modern laptop, and would take about 1 second for Bash to load 1 million entries. The startup delay and the memory usage is noticeable.

Storing the shell command history in a database instead of the memory of each interactive Bash shell, it would make Bash start up faster, and also use less memory.

Re: Stinkpot: SQLite-backed shell history

#35

Post by INTPenis »

NightMKoder wrote: post #6

FWIW I use atuin ( https://atuin.sh/ ) and am reasonably happy with it, especially the infinite capacity & snapiness. Ignoring the sync features, I believe it's also sqlite backed when running in local-only mode.

So can it run without AI? They promote their own AI on the website and that is really the last thing I want in my Shell

Re: Stinkpot: SQLite-backed shell history

#38

Post by superb_dev »

ptspts wrote: post #23

As indicated in https://tangled.org/oppi.li/stinkpot/blob/cdf87ffcd36e96f3d4... , this software (stinkpot) still uses Bash PROMPT_COMMAND as an entry point to copy new shell history entries to its database. PROMPT_COMMAND has the following flaw: a command gets recorded as soon as it has finished. So command which never finish (e.g. because they run for a long time, and the user closes the terminal window, or reboots…

What would be a better entry point? I honestly thought there would some hook for saving history specifically

Re: Stinkpot: SQLite-backed shell history

#39

Post by inigyou »

superb_dev wrote: post #38
ptspts wrote: post #23

As indicated in https://tangled.org/oppi.li/stinkpot/blob/cdf87ffcd36e96f3d4... , this software (stinkpot) still uses Bash PROMPT_COMMAND as an entry point to copy new shell history entries to its database. PROMPT_COMMAND has the following flaw: a command gets recorded as soon as it has finished. So command which never finish (e.g. because they run for a long time, and the user closes the terminal window, or reboots…

What would be a better entry point? I honestly thought there would some hook for saving history specifically

Modify bash?

Re: Stinkpot: SQLite-backed shell history

#40

Post by exiguus »

lucideer wrote: post #28

I would never normally mention this, but I'm reading this repo on mobile & it seems Forgejo doesn't wrap .txt files on mobile. Any reason not to use .md for a new project in 2026?

I looked it up, because for me it looked kind of cool. It's tangled not Forgejo when i got it right.

[1] https://tangled.org/

Post reply on HN