Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 end-user customization.

One thing that might be interesting is to support a hook for the ! syntax, so the sqlite DB could be searched. I think that would solve some of the problems you mention in the code's comments, and maybe the fzf issue. (Although that literally just occurred to me, I don't promise to do this :) )

I haven't looked at how fzf works exactly. But if you want to chat about it please chime in on Github :)

[1] Latest status: Success With the Interactive Shell http://www.oilshell.org/blog/2019/02/05.html . Oil runs a bunch of interactive programs like bash-completion, virtualenv, and git-prompt!



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


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


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.


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'


"As if there was no tomorrow" - exactly, because once you add another column suddenly $4 points to something completely different and you have to rewrite everything.

Not to mention $4 is completely arbitrary and it's impossible to tell without prior knowledge which field it's referencing.

The original query `SELECT pwd, cmd WHERE exit-code != 0` is both descriptive and won't break with future updates.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: