Comment by skissane | Hacker News Reader

Comment by skissane | Hacker News Reader

Parent Full thread

Storing history in SQLite is such a wonderful idea, I wonder why someone doesn’t just add it to readline/libedit/etc, then all apps (which use those libraries) can do it.

Although, I wonder if that might cause problems, if apps already link to SQLite and they might expect a different version, or if unstable apps might cause concurrency/corruption/etc issues with a shared per-user history DB. To avoid all that, maybe a per-user history daemon with a Unix domain socket?

Slightly silly sketch (bash):

    sqlite-utils create-table ~/commands.db commands id integer text text --pk id
    PROMPT_COMMAND="( fc -n -l -1 | perl -p -e 's/^\s+//; chomp if eof' | sqlite-utils insert --text ~/commands.db commands - & )"

It's slow, has perl & python external deps, needs a timestamp column, call subshell to avoid job control messages, ...

A nicer single "prompt command" wrapper is certainly possible though.

The xonsh shell can use sqlite for history. Really useful, also contains runtime statistics, for instance. I used xonsh for a few weeks. It is absolutely an awesome shell, but I didn’t find the switch worth the effort personally.

Reply on news.ycombinator.com