The Erlang Shell

Erlang News & Announcements Official Proposals
61

An easy way to save the result/session to a file would be nice. Something like \o in psql. Useful when debugging a system, when evidence/state needs to be collected quickly for later analysis.

5 Likes
62

There are two separate streams of output coming to the shell:

  1. The commands your type and what they return
  2. Things printed by io:format in the application

Do you have any suggestions about which streams should be part of the log? if configurable, what should be the default?

Another useful feature in the same area would be for -remsh to be able to store a log of the current session at both the remote and local node.

2 Likes
63

I donā€™t recall having to redirect io:format stream, so personally, Iā€™d probably default to capturing the commands I type and what they return. Of course there could be other uses cases.

2 Likes
64

Re Home/End:

Ctrl+A / Ctrl+E serves that purpose, no?

I also found that Option + Left/Right arrow skips over words. Remembering all these tricks is my difficulty.

2 Likes
65

It does yes, butā€¦

Itā€™s easier to remember when they are standard Mac shortcuts - CMD+left/right usually jump to the beginning end of line with Option+left/right skipping words in most text editing apps, just as Mail, Notes, TextMate, TextEdit etc. (Itā€™s good that Option+left/right does the same as Ctrl+A / Ctrl+E so itā€™s a bit easier to remember, or remember once you try CMD+left/right and see that it does not work :lol:)

1 Like
66

Another useful feature might be to be able to have a custom pluggable formatter of the output printed in the shell. E.g. if one wanted to modify the way how textual binaries are printed from <<"...">> to something like ā€œā€¦ā€, it would be easily achievable with a plugin.

2 Likes
67

A couple of years ago we experimented with allowing custom formatters to be able to display things such as dict and array in a more human-readable format. I donā€™t recall exactly the reason why that effort was dropped, but I think it had something to do with the performance of printing and depth-limiting of printed terms. Maybe @kennethL remembers more?

2 Likes
68

@frazze just opened a new PR for better autocompletion in the Erlang shell. Please have a look and put any feedback in the PR. Some quick example code:

> erl
Erlang/OTP 25 [RELEASE CANDIDATE 2] [erts-12.3] [source-b4c62d6ccd] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]

Eshell V12.3  (abort with ^G)
1> lists:foldl(<TAB>
fun(Elem :: term(), term() -> term())    

1> lists:foldl(fun(A, Acc) -> A + Acc end, <TAB>
term()    
1> lists:foldl(fun(A, Acc) -> A + Acc end, 0,  <TAB>
[term()]    
1> lists:foldl(fun(A, Acc) -> A + Acc end, 0, [1,2,3]).
6
2> file:open("lib/<TAB>
..               .gitignore       Makefile         TAGS             
asn1             common_test      compiler         crypto           
debugger         dialyzer         diameter         edoc             
eldap            erl_docgen       erl_interface    et               
eunit            ftp              inets            jinterface       
kernel           megaco           mnesia           observer         
odbc             os_mon           parsetools       public_key       
reltool          runtime_tools    sasl             snmp             
ssh              ssl              stdlib           syntax_tools     
tftp             tools            wx               xmerl            
2> file:open("lib/std<TAB>
2> file:open("lib/stdlib/
2> file:open("lib/stdlib/src/so<TAB>
2> file:open("lib/stdlib/src/sofs.erl"
2> file:open("lib/stdlib/src/sofs.erl").
{ok, D}

It is a work in progress, so keep that in mind when looking at the PR. I think it is a great start at better auto completion.

12 Likes
69

It would be nice to add console functionality to the Erlang documentation.
I have seen how it nice work in the Rust programming language documentation. I love it.

One
item1

Two

item2
item21200Ɨ570 28.1 KB

Three

item3
item31200Ɨ581 33.4 KB

Something similar has already been tried.

Here is a description of such an attempt.

item4

Try Erlang online supplement to the book ā€œErlang Programmingā€ https://www.tryerlang.org/ - educational online supplement to the book ā€œErlang Programmingā€. It is implemented as a console, emulating the behavior of erl/werl consoles.

The application is multifunctional: it is a tutorial, the behavior of which can be controlled by following the instructions described under the console window. You can jump to the previous or next section by entering the prev commands. and nextā€¦ is the console that allows you to run the bookā€™s examples. is a console that allows you to see the results of many functions

About numerous hacker attacks and protection against them, the author of this project shared on the pages of his blog - More details in the article Try Erlang | VK.

This application was implemented under the influence of the https://tryhaskell.org/ project.

3 Likes
70

Here is a small recording on what weā€™re able to autocomplete thus far:

18 Likes
71

Awesome

4 Likes
72

Fantastic. Even just the completion of currently-bound variables is quite a game-changer.

5 Likes
73

Are you just extending the ā€œoldā€ edlin_expand API? Would be very nice for me as it would automatically carry over to my Jupyter kernel implementation :wink:

2 Likes
74

The one thing that amazes me more than that people can work on those tiny keyboards is that there are people who want to do just that. I mean, why do people who sit in front of screens whose size often dwarfes a cinema like to type on those flimsy things that are stripped of some of the most crucial keys, or cram them in the most awkward of places :roll_eyes:

Just joking :stuck_out_tongue_winking_eye:

Anyway, I have seen many people requesting all sorts of keyboard shortcuts. As different (OS-ish) shells have different shortcuts for different things, finding a common, one-size-fits-all setup will be difficult, so I think those should be configurable and come with reasonable defaults depending on the shell and/or OS where they are used. (But I wonā€™t need many of those anyway, since Iā€™m using a proper, full-size keyboard :grin:)

Apart from that, yes, syntax coloring would be nice, maybe with nested brackets in different, corresponding colors.

Oh, and a quick and easy way to turn output truncation on and off. The shell has a habit of cutting off and going all ellipsis just before the point where it gets interesting. There probably is a way to do that right now, but I can never remember when I need it and canā€™t be bothered to look it up, so I usually turn to io:format :sweat_smile:

9 Likes
75

As a non american I can also add different keyboard layouts to the mix of reasons for ā€œone size fits allā€ being problematic :slight_smile:

3 Likes
76

Yes, but I have to read a map with variable bindings and an ets table with the loaded records and their types. How we load records might change though, weā€™re thinking of maybe loading the records dynamically as you need them in your prompt.

For example if mod:fun expects a #some_record, then we can look it up and display the contents of the #some_record
mod:fun(#some_record{

But if you would just type the record in isolation, the shell would not know where #some_record lives and in that case you would need to load them with rr(), and provide that table to edlin_expand
#some_record{<tab

3 Likes
77

One of the nice things about using the readline library proposed above in this thread is that it already has solved the problem of different key-bindings for different OSs. But alas it seems like we cannot use it.

On the other hand, I quite like that Erlang has the same key binding no matter if I am on windows, macos or Linux. But I think Iā€™m rather unique in using erlang on all of those platforms almost every day.

I use the shell built in function rp/1. I.e. rp(v(-1)). However, adding a command line shortcut to gradually increase the depths of the previously returned term could be very neat.

3 Likes
78

I think there are two main reasonsā€¦ ergonomics (low profile and mouse not too far away) and wanting to keep your desktop keyboard as close as possible to your laptop keyboard to make switching as effortless as possible :smiley:

If they are using platform-dependent keys (so the Command key on the Mac) then I think it may be ok? I agree it could be a nightmare trying to find common ground for shared keys like Control and Alt :lol:

Have you thought about adding FreeBSD to that mix too Lukas!? :003:
(Iā€™d still be curious to learn what, if any, advantages there are using FreeBSD with Erlang if anyoneā€™s reading this who might know!)

2 Likes
79

I did have freebsd on my home server before, but Iā€™ve yet to start it up since my last move. And from the perspective of shells, all OSs behave basically the same except MacOS and Windows.

2 Likes
80

Heh :wink: Reminds me, when I was a kid, my father brought home some russian model ā€œcomputerā€ that he got second hand. It had a tiny ā€œkeyboardā€ set in a wooden frame, with 4 ALT keys to access the 4 layers of symbols imposed on each keyā€¦ :rofl: Those were the days :star_struck:

5 Likes