Live data from Hacker News

Stinkpot: SQLite-backed shell history

tangled.org

21–30 of 44 posts

Re: Stinkpot: SQLite-backed shell history

#21
post #16
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…

I use SQLite history to have context aware line suggestion in my shell. So the command that gets ghost displayed (and can be expanded with right arrow) depends on the current working directory, its parents and recency. This is fast enough using SQLite to just dump all commands into it and query on each typed letter.

The DB is at this point 10years old. I use it to evaluate my work habits and patterns. More recently I have started transitioning to a different shell and I used it to move only the functions and aliases I still use, instead of the full collection.

Re: Stinkpot: SQLite-backed shell history

#22
I recently “fixed” my bash history since the default experience when using multiple terminals sucks.

https://dandavis.dev/the-bash-history-i-always-wanted.html

I also use fzf to search my history I believe you just need so source the right keybindings file to make ctrl+r use fzf.

Re: Stinkpot: SQLite-backed shell history

#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 the system) never get recorded. Another flaw: the users starts a long-running command in terminal window 1, and immediately they want to start a variant of it in terminal window 2, but it's not available in the history.

Re: Stinkpot: SQLite-backed shell history

#24
For me personally, while I like the history element, if I'm gathering/storing/searching everything, I'd love to also see the command output with the entered command, giving much better context.

Currently I tend to log all my ssh sessions out to text files and grep through the whole lot to find what I want, so a better version of that would be lovely, especially if it could automatically redact secrets or similar, as I'm aware thats a downside of the current setup.

Re: Stinkpot: SQLite-backed shell history

#26
How do these compare to the fish builtin history search with dir awareness and completion menu? I found it quite an improvement to bash history handling but fish isn't POSIX compatible so sometimes you need to switch back and forth.

Re: Stinkpot: SQLite-backed shell history

#27

I recently “fixed” my bash history since the default experience when using multiple terminals sucks. https://dandavis.dev/the-bash-history-i-always-wanted.html I also use fzf to search my history I believe you just need so source the right keybindings file to make ctrl+r use fzf.

Have you tried http://atuin.sh

Re: Stinkpot: SQLite-backed shell history

#29
post #26

How do these compare to the fish builtin history search with dir awareness and completion menu? I found it quite an improvement to bash history handling but fish isn't POSIX compatible so sometimes you need to switch back and forth.

As a user of atuin, it also keep track of the status code of a previous command, as well as its execution time.

It’s quite handy.

Post reply on HN