[erlang-questions] Starting EShell via code

[Paul Davis]

Here's a working example based on a talk by Geoff Cant.

https://gist.github.com/davisp/439e29ced1e6a9d2b108

I was playing around trying to get tab completion working based off
the code loaded in the remote node. I haven't used it extensively but
tab completion and arrow keys move just fine.

Paul

On Sat, Sep 20, 2014 at 3:54 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> Gonna answer both emails at once here.
>
> On Saturday, September 20, 2014, James Hague <james.hague@REDACTED> wrote:
>> Under OS X Mavericks and Erlang/OTP 17 I can start a working EShell easily
>> enough from code, but some keys don't behave the same as the default shell:
>> no tab completion, no arrow key movement.
>>
>> What am I missing?
>>
>
> How are you starting things? Usually, tab completion and arrow movement
> is done through a ping pong between edlin.erl and group.erl:
>
> https://github.com/blackberry/Erlang-OTP/blob/master/lib/stdlib/src/edlin.erl
> https://github.com/blackberry/Erlang-OTP/blob/master/lib/kernel/src/group.erl
>
> The input and display of a few characters that are broken can be due to
> having used the old shell (which didn't handle these and was implemented
> in user.erl, an older and rarely used version of the shell:
> https://github.com/blackberry/Erlang-OTP/blob/master/lib/kernel/src/user.erl)
>
> I tried to document the general structure of the Erlang shell in
> http://ferd.ca/repl-a-bit-more-and-less-than-that.html.
>
> You can read my response to José below where I do mention a way that
> appears to work decently to programatically start a shell.
>
> On 09/20, José Valim wrote:
>> Afaik there is no easy way to *correctly* start the shell after the
>> VM boots because the user and group processes have already been registered.
>> You always get a limited version of the shell.
>>
>
> This can be specified by some special trickery by starting with -nouser,
> which will start no shell, no user, etc. and then having to substitute
> in your own mechanisms to try and handle it with the special file
> descriptor {fd, 0, 1} (stdio, stdout) and {fd, 2, 2} (stderr), and
> moving them around.
>
> The problem there is that things may also depend on the tty program
> being around.
>
> Something similar is done with 'rebar shell' as a command, which
> nevertheless hijacks the current IO stuff by killing it, and taking over
> talking with the tty program -- though these are somewhat constrained by
> virtue of running in an escript:
> https://github.com/rebar/rebar/blob/master/src/rebar_shell.erl
>
> That stuff still leaves a few things a bit wonky here and there from
> what I've seen using it, but generally seems to do an okay job.
>
>
> Regards,
> Fred.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions