I Cannot Get a Result from a Single Line Put into the Erlang Shell

I cannot get a result from a single line put into the Erlang shell

You must type : 20+30.
Don't forgot DOT.
Hope i can help you.... :D

No output or error message from Erlang shell

This looks like there were an initial ' or " in the command line. So the shell is waiting for the second ' or " which closes the atom or string declaration. It prints the evaluation result and is now ready for the next command.

Look at this example in the console (started with erl):

Eshell V10.6.2  (abort with ^G)
1> io:format("Hello world!").
Hello world!ok
2> io:format("Hello world!             ).
2> ".
* 2: syntax error before: '.'

Erlang Console does not give any output (on Windows)

You need to end the command with a dot:

cd("C:/").

How run an Erlang application inside the Erlang shell

A typical directory structure for a Rebar-powered OTP application is something like this:

/
  src/
  ebin/
  deps/
    dep1/
      src/
      ebin/
    dep2/
      src/
      ebin/

So, if you're in the root directory of your project, you can point erl to the right place with the -pa argument. To tell it where to find both your application's and its dependencies' BEAM files, try the following:

erl [...] -pa ebin -pa deps/*/ebin

Why second call to receive doesn't retrieve a message in Erlang shell?

The first receive binds the variable V to 1, so the second receive becomes:

receive 
    1 -> ...

end

And, because the message 1 never arrives, the second receive times out. After the timeout, you can call flush() in the shell, and you will see that there was a message 2 in the mailbox. You can also call b() at any time to display the current variables and their values (which are known as bindings)--try that after executing the first receive.

In your function, you are also doing a recursive receive within a receive within a receive such that the first receive never ends. To prove that, you can put a print statement after:

Receiver(New)

like:

io:format("receive ending with Current= ~w~n", [Current])

and you will never see any output. You should change your receive to something like this:

New = Currrent + 1
receive
  Sender ->
    io:format("  -- Sending ~p to ~p~n", [New, Sender]),
    Sender ! New,
    io:format("receive ending with Current= ~w~n", [Current])
end,
counter(New).

The erl program outputs different values than what is output by the erlang shell

From the docs:

-s Mod [Func [Arg1, Arg2, ...]](init flag)

Makes init call the specified function. Func defaults to start. If no arguments are
provided, the function is assumed to be of arity 0. Otherwise it is
assumed to be of arity 1, taking the list [Arg1,Arg2,...] as argument.
All arguments are passed as atoms. See init(3).

1. Because of this line:

   If no arguments are
   provided, the function is assumed to be of arity 0. Otherwise it is
   assumed to be of arity 1, taking the list [Arg1,Arg2,...] as argument.

   your function is going to receive a list as the sole argument.

2. Because of this line:

   All arguments are passed as atoms.

   all the arguments in the list are going to be atoms.

Therefore, you need to pick out the head of the list to get the sole argument, and then you have to convert the atom to an integer in order to use the == comparison with another integer. Like this:

-module(fib).
-export([my_function_3/1]).

my_function_3([Arg1|_Rest]) ->
    Arg1Int = list_to_integer(atom_to_list(Arg1)),
    print_result(Arg1Int).

print_result(Arg1) when Arg1<3 ->
    io:format("<3~n");
print_result(Arg1) when Arg1==3 ->
    io:format("=3~n");
print_result(Arg1) when Arg1>3 ->
    io:format(">3~n").

Note that in erlang, a term can be compared to another term of any type, and it will not cause an error. That's because in erlang all types are given a particular order:

number < atom < reference < fun < port < pid < tuple < list < bit string

As you can see a list is considered to be greater than a number, hence the reason that your Arg1, which was a list, was always considered greater than the number 3.

executing single line commands with erl executable?

You can run small Erlang programs from the command line using the eval option. For example:

erl -noinput -eval 'io:format("hello world~n").' -s init stop

You can read the erl man page for more details on command-line options, but briefly:

• -noinput means there's nothing for the runtime to read
• -eval treats its argument as Erlang code text to evaluate and execute
• -s init stop executes the init:stop/0 function to shut down the runtime

To print the current date and time, you can take a similar approach:

erl -noinput -eval '{{Y,Mo,D},{H,Mi,S}} = calendar:now_to_local_time(os:timestamp()),
  io:format("~4.4w-~2.2.0w-~2.2.0w ~2.2.0w:~2.2.0w:~2.2.0w~n",[Y,Mo,D,H,Mi,S]).' -s init stop

This code retrieves the current time using os:timestamp/0, converts it to local time via calendar:now_to_local_time/1, and then formats that result using io:format/2, producing a result like this:

2014-10-22 10:09:53

Running erlang shell command, via console, in an already-running shell

Why have you to run a command from zenity but not just grab result? (Or you can run echo.)

1> Port = open_port({spawn_executable, os:find_executable("zenity")}, [in, {line, 65536}, eof, {args, ["--calendar", "--title=Holiday Planner"]}]).
#Port<0.490> 
2> flush().
Shell got {#Port<0.490>,{data,{eol,"10/20/2016"}}}
Shell got {#Port<0.490>,eof}
ok

Cannot spawn an erlang supervisor from the shell

This explanation was given by Bernard Duggan on the Erlang questions mailing list:

Linked processes don't automatically
die when a process they are linked to
exits with code 'normal'. That's why
[echo_server] doesn't exit when the
spawning process exits. So why does
the supervisor die? The internals of
the supervisor module are in fact
themselves implemented as a
gen_server, but with
process_flag(trap_exit, true) set.
The result of this is that when the
parent process dies, terminate() gets
called (which doesn't happen when
trap_exit is disabled) and the
supervisor shuts down. It makes sense
in the context of a supervisor, since
a supervisor is spawned by its parent
in a supervision tree - if it didn't
die whenever its parent shutdown,
whatever the reason, you'd have
dangling "branches" of the tree.

---

Related Topics