[erlang-questions] Erlang Shell History: enabled.

Andrew Berman rexxe98@REDACTED
Tue Nov 22 19:16:44 CET 2011

This rocks!  Thank you for this!

On Tue, Nov 22, 2011 at 7:05 AM, Chad DePue <chad@REDACTED> wrote:

> Agreed - think of the thousands of hours that could have been (and now
> will be) saved with this! So cool...
> Chad DePue
> inakanetworks.com - development consulting | skype cdepue | @chaddepue
> +1 206.866.5707
> On Tue, Nov 22, 2011 at 10:32 AM, Joe Armstrong <erlang@REDACTED> wrote:
>> Hip hip horray - "for he's jolly good fellow, ....
>> Anything that saves my fingers is good.
>> This is very nice - this is one of those small improvements that never
>> gets done, only
>> now it has been. I don't know how many times I've restarted the shell and
>> cut and paste
>> commands from the old shell ...
>> Works like a charm - now all we need is "search history backwards for
>> regexp with tab completion -
>> and dwim mode". I'm a terrible typist so dwimming my inputs would be
>> fantastic.
>> Cheers
>> /Joe
>> On Mon, Nov 21, 2011 at 7:23 PM, Fred Hebert <mononcqc@REDACTED> wrote:
>>> Hi everyone,
>>> 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
>>> Erlang shell.
>>> I'm presenting the result of the quick hack:
>>> https://github.com/ferd/erlang-history
>>> 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.
>>> Options include:
>>> - hist - true | false: enables or disables shell history. Default value
>>> is true
>>> - 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
>>> Erlang/OTP team.
>>> Let me know what you think of it. Also: enjoy!
>>> Have a nice day, everyone.
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111122/d36c24dc/attachment.htm>

More information about the erlang-questions mailing list