Live data from Hacker News

Better Bash History (2012)

sanctum.geek.nz

61–70 of 85 posts

Re: Better Bash History (2012)

#61
post #47

Because this comes up every so often, I'll post this link again: I wrote a little widget that stores your bash history in a sqlite db. I haven't touched it in a while because I now rely on fzf and this doesn't integrate with it, though maybe I could make it do... https://github.com/thenewwazoo/bash-history-sqlite

This is cool, somebody recently suggested that I add history to sqlite in Oil [1]. I looked at your code but I didn't see how it integrates with bash? Most people seem to be using the PROMPT_COMMAND hook for stuff like this -- are you using something else, or did I miss it? https://github.com/oilshell/oil/issues/320 I will add PROMPT_COMMAND to Oil, but I'm curious if there is something else I should add to support e…

> This is cool, somebody recently suggested that I add history to sqlite in Oil

I think a shell with an embedded sqlite, which makes sqlite accessible to scripts as shell builtins, and in which command line history is stored in a sqlite database instead of a plain text file, would be pretty cool. You could store command history (and maybe even other stuff) in something like $HOME/.shell_db As well as just a list of lines, other useful information could be stored for each line, such as current directory, timestamp, username (maybe I su to root and am running commands as root but still going into my own account's history database), hostname (if $HOME is on NFS, putting aside the issue that databases, including sqlite, don't work well over NFS due to file locking issues), etc.

Re: Better Bash History (2012)

#62
post #2

highly recommended for fellow ctrl-r addicts: https://github.com/junegunn/fzf

fzf is the most fun and productive tool added in my dotfiles in recent years.

Mix it with https://github.com/rupa/z or https://github.com/skywind3000/z.lua for fuzzysearch/cd

And you can do cool scripts, like:

- search your vim edited files with highlighted preview: https://github.com/BarbUk/dotfiles/blob/master/shell/complet...

- search and open your chrome history: https://github.com/BarbUk/dotfiles/blob/master/shell/complet...

Re: Better Bash History (2012)

#63
post #47

Because this comes up every so often, I'll post this link again: I wrote a little widget that stores your bash history in a sqlite db. I haven't touched it in a while because I now rely on fzf and this doesn't integrate with it, though maybe I could make it do... https://github.com/thenewwazoo/bash-history-sqlite

This is cool, somebody recently suggested that I add history to sqlite in Oil [1]. I looked at your code but I didn't see how it integrates with bash? Most people seem to be using the PROMPT_COMMAND hook for stuff like this -- are you using something else, or did I miss it? https://github.com/oilshell/oil/issues/320 I will add PROMPT_COMMAND to Oil, but I'm curious if there is something else I should add to support e…

> somebody recently suggested that I add history to sqlite in Oil

what a disgusting, perturbed mind! Shell history is probably the kind of data that fits better as a text file. It is naturally textual and it can never grow too long, even if you are typing commands continuously for your entire life. Please, keep the dirty hands of sql far, far away from the shell!

Re: Better Bash History (2012)

#64

To echo what everyone else is saying, get FZF. Most of these linux productivity things are just some dumb pet project that solves a specific problem that a specific person finds annoying. FZF is not this - it makes something you do hundreds of times a day (history and file opening on zsh, bash, fish, whatever) indisputably better. If you find yourself sitting there tapping ctrl+r multiple times like an idiot for some…

https://github.com/junegunn/fzf for the uninitiated

Re: Better Bash History (2012)

#65

I set up my bash config to store history separately for each working directory (ie separate history files that I store under a $HOME/.bash_history_d directory) – so as I cd into a project directory, the history is populated with the commands that I've run within that directory . I find this super-helpful to remind me of the context for projects – cd in, then up-arrow to whatever that command is I usually run to launc…

I use one bash history (and fasd history) per tmux session: [link redacted]

Re: Better Bash History (2012)

#66
post #44

Earlier quoted context omitted.

zsh-histdb stores history inside a sqlite database instead of a simple text file. The good thing is that it includes context: current directory, session, date. I use it together with ssh-suggestions which can use SQL queries to find the most relevant command. You can program rules such as: use the most frequent command in that session, if you none do it for the current directory in the last 6 months, if not, search g…

isn't that totally opposite of the *nix philosophy of everything is a text file?

There are plenty of non-text files around. Utmp comes to mind. And the text history is still there.

Re: Better Bash History (2012)

#67
post #7

>By default, Bash only records a session to the `.bash_history` file on disk when the session terminates. This means that if you crash or your session terminates improperly, you lose the history up to that point. I kept loosing my history consistently on my new installation because of this. I usually put my laptop to sleep, and pretty much never intentionally terminate my x-session except on kernel updates. But becau…

I have a fairly expensive ThinkPad and it also runs out if battery if asleep for more than about 4 days, and frequently freezes on suspend or resume when it's been both suspended and resumed docked and undocked. (Linux, of course.)

Re: Better Bash History (2012)

#68

I set up my bash config to store history separately for each working directory (ie separate history files that I store under a $HOME/.bash_history_d directory) – so as I cd into a project directory, the history is populated with the commands that I've run within that directory . I find this super-helpful to remind me of the context for projects – cd in, then up-arrow to whatever that command is I usually run to launc…

It's a great idea. If you additionally also like working with chroots you might find containers an interesting topic.

Basically a container let's you wrap a part of your filesystem, network, process space in a separate world of its own. And in that world you have only the context related stuff like history, processes, libs etc. Additionally most container environments come with tooling that enables you to make everything reproducable, so that you can share your container with others.

The great thing is you can always live in global space, while switching between what that global space means.

Re: Better Bash History (2012)

#69

I set up my bash config to store history separately for each working directory (ie separate history files that I store under a $HOME/.bash_history_d directory) – so as I cd into a project directory, the history is populated with the commands that I've run within that directory . I find this super-helpful to remind me of the context for projects – cd in, then up-arrow to whatever that command is I usually run to launc…

It's a great idea. If you additionally also like working with chroots you might find containers an interesting topic. Basically a container let's you wrap a part of your filesystem, network, process space in a separate world of its own. And in that world you have only the context related stuff like history, processes, libs etc. Additionally most container environments come with tooling that enables you to make everyt…

How would one go about setting up a container?

Re: Better Bash History (2012)

#70
post #50
post #20

Earlier quoted context omitted.

I also recommend FZF. Really very handy for doing CTRL-R searches. I also use it for doing interactive git rebases. I have an alias for doing a fuzzy rebase interactive (frbi): frbi = !git rebase -i $(git log --pretty=oneline --color=always | fzf --ansi | cut -d ' ' -f1)^

This is a great idea, thanks for it! I've done similar things with using fzf to git add, git diff, and so on, but I hadn't thought of using it to pick a commit to rebase from. I made a few changes so I figured I'd post them back here in case you're interested: pick-commit = # equivalent to your git log... cut... rif = "!f() { rev=$(git pick-commit); [[ $rev ]] && git ri $rev~; }; f" "rif" = "rebase interactive fzf/fu…

Thanks for that. I like your improvements to my idea too! :)
Post reply on HN