[erlang-questions] [Erlang-Q] What does Ctrl+G do for the Eshell?

22 views
Skip to first unread message

Barco You

unread,
Oct 3, 2011, 3:28:49 AM10/3/11
to erlang-questions
Hello Erlangers,

When starting a erl shell, we will see a printout as:
Eshell V5.8.4 (abort with ^G)


then, I tried to press Ctrl+G and got:
User switch command
--> ls
Unknown command
--> q().
Unknown command
-->

I can do nothing with the prompt "-->". How to quit from it? and
what's "Ctrl+G" used for?


Thank you!
Barco
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

CGS

unread,
Oct 3, 2011, 3:31:52 AM10/3/11
to erlang-q...@erlang.org
Try q instead of q(). You may also want to try h.

Cheers,
CGS

Ahmed Omar

unread,
Oct 3, 2011, 3:51:30 AM10/3/11
to CGS, erlang-q...@erlang.org
Hi Barco, 
I also recommend to check out 
--
Best Regards,
- Ahmed Omar
Follow me on twitter

Anders Ramsell

unread,
Oct 3, 2011, 6:13:09 PM10/3/11
to erlang-questions
Barco You wrote:
> Hello Erlangers,
>
> When starting a erl shell, we will see a printout as:
> Eshell V5.8.4 (abort with ^G)
>
>
> then, I tried to press Ctrl+G and got:
> User switch command
> --> ls
> Unknown command
> --> q().
> Unknown command
> -->
>
> I can do nothing with the prompt "-->". How to quit from it? and
> what's "Ctrl+G" used for?
>
>
The words "abort with ^G" are in fact hiding an extremely useful
function called JCL (job control mode) [1]. I overlooked this
function for years. Now I use it on a near daily basis and just
love it.

[1] http://www.erlang.org/doc/man/shell.html

Assume you have an Erlang node named 'server@myhost' running as a
service/daemon on your system. Wouldn't it be great if you could
run interactive commands on this node just like you do in a
shell? JCL let's you do that with ease.

Start up a new shell 'client@myhost' and hit ctrl-G to enter JCL.
Now start a remote shell to 'server@myhost'.

| (client@myhost)1>
| User switch command
| --> r server@myhost
| --> j
| 1* {shell,start,[init]}
| 2 {server@myhost,shell,start,[]}

You now have a local shell with id=1 and a remote shell with
id=2. Connect to the remote shell:

| --> c 2
|
| (server@myhost)1>

Now you have a shell on the server node where you can run any
command you want. This means you can call any exported function
in all modules loaded on the server. That kind of interaction
with a running system can be invaluable when trying to figure out
why it doesn't behave quite the way you planned.

Now of course there is a backside to the story. Doing something
wrong may cause your system to crash. So hey - let's be careful
out there.

/Anders

Steven Yu

unread,
Oct 3, 2011, 6:22:53 PM10/3/11
to Anders Ramsell, erlang-questions
Hi,

Not sure if its fixed in R14 but why when running <r> without specifying node in user switch command your local erlang crashes? e.g.

User switch command
 --> r
{error_logger,{{2011,10,4},{0,18,25}},supervisor_report,[{supervisor,{<0.26.0>,user_sup}},{errorContext,child_terminated},{reason,{noproc,{gen_server,call,[{global,pool_master},get_node]}}},{offender,[{pid,<0.28.0>},{mod,user_sup}]}]}......

Can this behaviour be changed?

Regards,

Barco You

unread,
Oct 4, 2011, 2:31:21 AM10/4/11
to Anders Ramsell, erlang-questions

Such a fabulous facility! Thank-you for telling!

Robert Virding

unread,
Oct 4, 2011, 7:54:25 AM10/4/11
to Barco You, erlang-questions
Hi,

It was created back in the days when we were thinking of Erlang as more of an OS where you could run multiple "jobs" at the same time. Apart allowing you to start many concurrent jobs, not just the shell, it also multiplexes the i/o so only the connected job (the 'c' command) gets access, both read and write, to the user terminal. I/o to the other jobs is blocked. Otherwise having mixed i/o to/from many jobs at the same time becomes a right mess.

The ^G works as all user terminal input passes through this layer. Now it should maybe be rewritten to use separate windows instead? If we ever get a "standard" window interface. :-)

The name JCL (Job Control Language) is a joke on IBM's JCL which they used back in the old days to control their batch jobs. It was if course completely different.

Robert


Barco You

unread,
Oct 4, 2011, 8:22:07 AM10/4/11
to Robert Virding, erlang-questions

A further question regarding the erlang shell. Can we run an application without running the shell? As I know, to run an erlang app I have to first start the shell and then app:start().

As you said, erlang is more than an OS, so can I understand in the way that an app cannot run when the OS (Eshell) is not started?

Thanks,
Barco
Sent from my HTC

On Oct 4, 2011 7:54 PM, "Robert Virding" <robert....@erlang-solutions.com> wrote:
> Hi,
>
> It was created back in the days when we were thinking of Erlang as more of an OS where you could run multiple "jobs" at the same time. Apart allowing you to start many concurrent jobs, not just the shell, it also multiplexes the i/o so only the connected job (the 'c' command) gets access, both read and write, to the user terminal. I/o to the other jobs is blocked. Otherwise having mixed i/o to/from many jobs at the same time becomes a right mess.
>
> The ^G works as all user terminal input passes through this layer. Now it should maybe be rewritten to use separate windows instead? If we ever get a "standard" window interface. :-)
>
> The name JCL (Job Control Language) is a joke on IBM's JCL which they used back in the old days to control their batch jobs. It was if course completely different.
>
> Robert
>

Gustav Simonsson

unread,
Oct 4, 2011, 8:46:03 AM10/4/11
to erlang-q...@erlang.org
See http://www.erlang.org/doc/man/erl.html
in particular the -noshell flag.

Regards,
Gustav Simonsson

Reply all
Reply to author
Forward
0 new messages