Live data from Hacker News

Better Bash History (2012)

sanctum.geek.nz

71–80 of 85 posts

Re: Better Bash History (2012)

#71
post #29

I do: promptFunc() { # right before prompting for the # next command, save the previous # command in a file. echo "$(date +%Y-%m-%d--%H-%M-%S) \ $(hostname) $PWD $(history 1)" \ >> ~/.full_history } PROMPT_COMMAND=promptFunc This is in addition to standard bash history, and is much more reliable. Being able to see not only what command I ran but what directory I was in and when I ran it is very useful. (I wrote about…

Yeah, this is how I do it - although I append the hostname to the end of the filename and sync the collection between my machines so that I can grep for history on any machine.

Edit: went to check and apparently I've overcomplicated this somewhat (it's about ten years old) but it is nice if empty lines are not logged. It's an old habit to ctrl-c then hit return repeatedly if a terminal is not responding.

  PROMPT_COMMAND=storehist

  storehist ()
  {
    CMDCNT=`history 1 | sed -e 's/\w* *\(.*\)/\1/'`;
    if [ "$CMDCNT" != "$LASTCMDIND" ] && [ -n "$LASTCMDIND" ]; then
        DATE=`date '+%Y%b%d %H%M'`;
        if [ "$LASTCMDIND" != "$CMDCNT" ]; then
            echo "$DATE $HOSTNAME:$BASHTTY $CMDCNT" >> ~/.custom_history;
        fi;
        LASTCMDIND="$CMDCNT";
    fi;
    LASTCMDIND="$CMDCNT"
  }

Re: Better Bash History (2012)

#72
I remember reading this article back when I was still using Bash. I've finally got the history I like only after switching to ZSH.

You can get decent history in ZSH just by setting the right options. If you want great history, you'll need to write a bit of code. Right now my history works as follows.

History is written to disk after every command. Up and Down keys go through the local history (from the same session). Ctrl+Up and Ctrl+Down go through the shared history (from all sessions). Ctrl+R also uses shared history (it's easy to add another binding for local history but I don't have it). Pressing Up/Ctrl+Up after typing something will go over history entries that have the matching prefix. For example, `git` will show the last command from the current session that starts with `git`. Here's my config: https://old.reddit.com/r/zsh/comments/bsa224/how_to_setup_a_....

In addition, my history is stored in Git. History from the local machine comes first, and from other machines second. This is fairly easy to do it Bash, too.

Re: Better Bash History (2012)

#73
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…

That looks great. Do you have your dotfiles shared by any chance?

Re: Better Bash History (2012)

#74
post #47

Earlier quoted context omitted.

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!

I can almost see the appeal, when you think of decorating it.

Consider a table with five columns:

* uid

* pwd

* cmd

* exit-code

* datetime

Now you can `SELECT pwd,cmd WHERE exit-code != 0` to see all failed-commands.

Re: Better Bash History (2012)

#75

Earlier quoted context omitted.

> 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!

I can almost see the appeal, when you think of decorating it. Consider a table with five columns: * uid * pwd * cmd * exit-code * datetime Now you can `SELECT pwd,cmd WHERE exit-code != 0` to see all failed-commands.

I see your "decorated" sql table, and I raise you my text file with five columns, that you can grep and sed and awk as if there was no tomorrow.

     cat history.txt | awk '$4 != 0'

Re: Better Bash History (2012)

#76

Earlier quoted context omitted.

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?

`docker run ` for instance

Re: Better Bash History (2012)

#77
post #50

Earlier quoted context omitted.

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…

That looks great. Do you have your dotfiles shared by any chance?

Sure: https://github.com/kbd/setup

Here's my git config with a bajillion aliases: https://github.com/kbd/setup/blob/master/HOME/.config/git/co...

Since git commands are one of the most common things to type, I alias all short git aliases like so: https://github.com/kbd/setup/blob/fd1f826a9365895b7a3b8b5c58...

(link to particular commit so line numbers stay correct). That way my workflow looks like:

    $ ga (fuzzy find files to add)
    $ gcm "commit message"
etc.

Re: Better Bash History (2012)

#78
post #47

Earlier quoted context omitted.

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!

Ha, thanks for the feedback... Yeah I don't want the sqlite dependency by default.

The fact that somebody managed to bolt it onto bash after the fact is interesting. Oil is all about having a better/sane shell programming language, so it should have better hooks that make such customization. But yes it doesn't need to be in the core.

Re: Better Bash History (2012)

#79

Earlier quoted context omitted.

> 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!

I can almost see the appeal, when you think of decorating it. Consider a table with five columns: * uid * pwd * cmd * exit-code * datetime Now you can `SELECT pwd,cmd WHERE exit-code != 0` to see all failed-commands.

Yeah I agree. In Oil I'm hoping to have the best of both worlds. That is, no silly quoting and parsing of strings, but also being able to use plain tools like "grep", and probably SQL.

https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil

Note that R has some popular packages that allow SQL syntax over data frames.

So basically the history file could be a textual table. You could trivially import it into a database, or you can just grep it.

Re: Better Bash History (2012)

#80
post #70
post #50

Earlier quoted context omitted.

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! :)

Yay. Btw, one more improvement. TIL xargs will skip blank inputs (depending on bsd/gnu xargs, flags etc...), so my version above:

    rif = "!f() { rev=$(git pick-commit); [[ $rev ]] && git ri $rev~; }; f"
can just be:

    rif = !git pick-commit | xargs -tI% git ri %~
Post reply on HN