[erlang-questions] Erlang Shell History: enabled.
Mon Nov 21 19:23:25 CET 2011
last week I was on a bus after work and decided to keep on going with a
small project started at the EUC hackathon -- adding shell history to the
I'm presenting the result of the quick hack:
It works by storing the lines entered beforehand in a DETS database in your
home directory (configurable). When you start a VM instance, it loads up
the old history and puts it into the shell so that the up and down arrows
let you use older function calls. It doesn't support things like h() and
v(N), given these have all kinds of weird quirks related to storing
ephemeral data on disk and loading them back after the fact (ports, refs).
I also do not support ctrl-r history search, only because that can be
implemented independently from the history bit.
It does support multiple nodes, should work fine without conflicts and at
worse will mix in the history between different shell jobs of a single node.
- hist - true | false: enables or disables shell history. Default value is
- hist_file - string(): gives the path to where the history should be
saved. By default, the file sits in your home directory as
.erlang-history.$NODENAME. The node name will always be appended to the
file name as a way to manage conflicts and names.
- hist_size - 1..N: how many input lines the shell should remember. By
default, the value is set to 500.
- hist_drop - ["some", "string", ...]: lines you do not want to be saved in
the history. As an example, setting hist_drop to
["q().","init:stop().","halt()."] will avoid saving most manual ways of
shutting down a shell. By default, no terms are dropped.
The options are all for the kernel application, so using the 'erl -kernel
hist_size 120' form or using -config files works.
DETS repairs work in case of a corrupted DB, although you can just drop the
file altogether if it takes too long. I don't drop files because I didn't
want to assume anyone did really want their history gone. I figure creating
a copy could have been fine, but I didn't think that far ahead.
There are no tests at this point. I might add a few of them later in the
future, testing the logic of a few private functions, but because the
group.erl file had no tests (that I could quickly find) in OTP, I decided
to go on with the simplest thing that can work. For this reason (no tests),
I assume this is *not* something worth submitting as patch to the
Let me know what you think of it. Also: enjoy!
Have a nice day, everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions