How to compile an Erlang application into executable binary and run it? - erlang

Now I am learning Erlang and I have a question about kind of running and testing Erlang applications.
We have some views of running and testing Erlang programs:
We can run Erlang shell and test in there our function.
We can compile some files with our Erlang code, than create .app file, and then again run Erlang shell and call application:start(AppName).
My question: Can we make binary executable file from Erlang code, Like C code? How can I run programmes without Erlang shell, in a way that I can run program, input something command and after that calls Erlang functions for this command?
For example I have a module (test.erl) with three functions:
foo1() -> ...
foo2() -> ...
foo3() -> ...
Then I want to run the programme in terminal and input -a flag to call function foo1, -b flag for foo2 and so on.

Let me divide the answer into three parts:
1. Running Erlang Applications
As Erlang source code (.erl files) compiled to BEAM bytecode (.beam files) and then run on top of Erlang virtual machine (BEAM), so There is no option for creating a stand-alone binary without the need of the virtual machine. But there are ways for packing, building, porting, upgrading and running Erlang applications based on OTP which is its formal platform.
A. Command-line flags
Imagine we developed an application with foo name, now we can start it with a set of flags just like this:
$ erl \
-pa path/to/foo \
-s foo \
-sname foo_node \
-setcookie foo_secret \
-noshell -noinput > /path/to/foo.log &
-pa adds the specified directory to the path
-s starts the foo application
-sname makes it distributed with a short name
-setcookie sets a cookie for making a minimum level of security
-noshell starts erlang without shell
-noinput doesn't let to read any input from shell
Then we can stop it with following command:
$ erl \
-sname stop_foo_node \
-setcookie foo_secret \
-eval 'rpc:call(foo, foo_node, stop, []), init:stop()' \
-noshell -noinput > /path/to/foo.log &
-eval evaluates the given expressions
And also we can attach to the foo application shell with this command:
$ erl \
-sname debug_foo_node \
-setcookie foo_secret \
-rmesh foo_node
-rmesh makes a remote shell to given node
We can put above commands into a makefile or shell script for using them simply.
Also for finer grained control over the start-up process of the system we can use a boot script file and specify it with -boot flag. The boot file contains instructions on how to initiate the system, which modules and applications we are dependant on, and also contains functions to restart, reboot and stop the system. The process of creating and using boot script is well documented in Erlang documentation website.
B. Release tool
The other way that automates and integrates most of the works for us is reltool which is a standard and fully featured release management tool. We can specify our application version, boot script, dependencies, and so on in reltool config file and create a portable release. This is a sample structure of an Erlang/OTP application compatible with reltool:
├── deps
│ └── ibrowse
├── ebin
│ ├── foo.app
│ ├── foo_app.beam
│ └── foo_sup.beam
├── rebar.config
├── rel
│ ├── files
│ ├── foo
│ └── reltool.config
└── src
├── foo_app.erl
├── foo.app.src
└── foo_sup.erl
We can use Rebar which is an Erlang build tool for making it even simpler to create Erlang application and also releases. There is a detailed tutorial on how to use Rebar for such task.
2. Testing Erlang applications
There are two standard test frameworks for Erlang applications:
Eunit: It is a standard unit-testing framework of OTP which can test a function, a module, a process or even an application.
CommonTest: It is another standard test framework of OTP that provides structures for defining local or distributed test scenarios and manages to run, log and report the results.
It is a common practice to combine them together for both white-box and black-box testing. Also Rebar provides rebar eunit and rebar ct commands for automating their execution.
3. Passing command-line argument
Using init:get_argument/1 we can retrieve user defined flags to decide upon them as follows:
$ erl -foo foo1 foo2 -bar bar1
1> init:get_argument(foo).
{ok,[["foo1","foo2"]]}
2> init:get_argument(bar).
{ok,[["bar1"]]}

No, you can't make a binary. You can write a bash- or escript to automatically run the startup / test code.

You should also be checking out eunit which can automate a lot of the hassle of running automated unit tests.

Related

How run an Erlang application inside the Erlang shell

I have an Erlang application and I can compile it easily and run it by using basho rebar which makes an stand-alone escript executable file. I run it from command line like: ./myapp myconfig.config
My questio is that how can I run it inside Erlang shell. This application has four other applications as dependency. Rebar compile all of the easily. But I need to run this application from inside the shell like:
erl -noshell -name node1#machine -run test start parameter1 -s init stop;
But I don't know in which path I should run it. When I try it in "ebin" folder (where beam files are located), dependencies are not accessible. As I see each dependency applications has it own "ebin" folder.
So how can I run my application by "erl -noshell" command (consider dependency applications)?
Rebar handles all these things automatically.
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

How do I start applications by command line as a daemon?

This has been my current routine
sudo nohup erl -sname foo -pa ./ebin -run foo_supervisor shell -noshell -noinput &
where the shell function looks something like this
shell() ->
{ok, Pid} = supervisor:start_link({local,?MODULE}, ?MODULE, _Arg = []),
unlink(Pid).
If I don't unlink from shell it immediately stops for some reason. Is there a way I can just start my application like I would normally ie application:start(foo). Also what if I want to start sasl too? Also where could I learn more about making a self contained package using rebar?
Preface. About your unlink
In this other SO thread #filippo explains why you need the unlink when testing supervisors from the shell.
First. What you need is an Erlang application.
Reading from the doc:
In OTP, application denotes a
component implementing some specific
functionality, that can be started and
stopped as a unit, and which can be
re-used in other systems as well.
Details on how to implement an Erlang application are available here. The three main things you will need to do are:
Have a proper directory structure for your application
Write an application callback module implementing the Erlang application behaviour. That's where you will start your root supervisor
Provide an application resource file. This is where you tell the system - among other things - where to find your application callback module (look at the mod parameter).
Second. Starting SASL.
In the above application resource file, you can specify a list of applications you want to start before your application. You will add something like:
...
{applications, [kernel, stdlib, sasl]},
...
To tell it to start SASL.
Third. Rebar.
There's an introduction to Rebar here, which explains you how to use Rebar to help you in the above steps, to pack your brand new application into an Erlang release and how to start it.

How to run Erlang from unix shell with complex params?

I need to run complex Erlang module function from unix shell
rpc:call('node#example.com', mnesia, dirty_first, [mytable])
how can i do it?
UPD:
i make test.escript
chmod +x test.escript
#!/usr/lib64/erlang/bin/escript
%%! -name 'test#example.com'
main(_Args) ->
R = rpc:call('node#example.com', mnesia, dirty_first, [mytable]),
io:format("~p~n",[R]).
and receive {badrpc, nodedown}
but when run
erl -name test#example.com
1> rpc:call('node#example.com', mnesia, dirty_first, [mytable]).
{my, data}.
I mean it works, but howto make escript work proprely?
I think escript might be something worth looking into.
Edit:
Some examples.
First for all examples: Start the remote node somewhere, somehow.
dannib#duval:~:> erl -sname bar
(bar#duval)1> erlang:get_cookie().
'KNKKCFPYMJUPIOLYPOAA'
Escript
1: Create a file named hello.escript with content
#!/usr/bin/env escript
%%! -sname foo#duval -setcookie KNKKCFPYMJUPIOLYPOAA
main(_String) ->
Node = 'bar#duval',
Mod = 'erlang',
Fun = 'node',
Args = [],
R = rpc:call(Node, Mod, Fun, Args),
io:format("Hello there ~p~n",[R]).
Notice that the %%! -sname foo#bar identifies the node on the host (instead of creating nonode#nohost), allow setting the same cookie %%! -sname foo#duvel -setcookie KNKKCFPYMJUPIOLYPOAA as target host which solves the problem of getting {badrpc,nodedown}. Notice that the same statement holds for the following examples (erl_call, and -eval) where both the node name and cookie is set.
2: Set the execution bit and run
$ chmod +x hello.escript
$ ./hello.escript
Hello there bar#duval
Erl_call
1: run
$ erl_call -c 'KNKKCFPYMJUPIOLYPOAA' -a 'erlang node' -n bar#duval
bar#duval
Eval
1: run
$ erl -sname foo -setcookie 'KNKKCFPYMJUPIOLYPOAA'
-eval 'io:format("Hello there ~p~n",[rpc:call(bar#duval,erlang, node, [])])'
... Eshell V5.7.4 (abort with ^G)
(foo#duval)1> Hello there bar#duval
This creates a shell which might not be what you want in this case.
I might mention that if both nodes are on the same host and using the same cookie default value, the cookie value for foo and bar don't have to be explicitly set like in the examples.
After doing these examples and reading your question again I think what I GIVE TERRIBLE ADVICE said will be your best choice, erl_call. I fell for the word "complex" in question title where imho escripts allow much more "complex" setups in a easy-to-read manner. The variable _String in the escript example holds the arguments to the script which allows you to both access input through shell and perform complex erlang operations in the EVM. But erl_call might be more straight forward if you already have logic in some other application and just need to make this simple call to an erlang node.
The erl_call application is exactly what you need:
erl_call makes it possible to start and/or communicate with a distributed Erlang node. It is built upon the erl_interface library as an example application. Its purpose is to use an Unix shell script to interact with a distributed Erlang node. It performs all communication with the Erlang rex server, using the standard Erlang RPC facility. It does not require any special software to be run at the Erlang target node.
The main use is to either start a distributed Erlang node or to make an ordinary function call. However, it is also possible to pipe an Erlang module to erl_call and have it compiled, or to pipe a sequence of Erlang expressions to be evaluated (similar to the Erlang shell).
See the examples for more details
You can use -eval flag of erl:
$ erl -eval 'io:format("Hello, World!~n")'
You can parse complex arguments with escript:
#!/usr/bin/env escript
main(String) ->
{Node, Mod, Fun, Args} = parse_args(String),
R = rpc:call(Node, Mod, Fun, Args),
io:format("~p~n",[R]).
If your problem is how to set the Erlang node in network mode (i.e. turn the node into a distributed node), you might want to do something like
EPMD = code:root_dir() ++ "/bin/epmd &",
os:cmd(EPMD),
net_kernel:start([Sname, shortnames])
where Sname is your wanted node name. Only after this can you start communicating to another node with e.g. rpc.

Add Path to Erlang Search Path?

I recently installed Erlang RFC4627 (JSON-RPC) with the debian package. I ran the test server using:
sudo erl -pa ebin
and then at the prompt:
test_jsonrpc:start_httpd().
returned
ok
I tested with http://:5671/ and got the success messages.
When I try to run rabbitmq-http2 however, I get the errors that the readme says are caused by rfc4627's code not being on the erlang search path. How do I put it on the path. I saw something on Dave Thomas's blog which suggested putting the path in the file:
~/.erlang
This didn't seem to work for me (maybe I did it wrong?).
The code module is how you manipulate the path within an application.
The flags -pa that you used in starting the Erlang shell actually refer to a function in this module:
add_patha(Dir) -> true | {error, What}
You are right about the .erlang file in your home directory - it is run at start-up time of the shell and you can add in handy paths.
For an application you can start the shell with a batch file that calls something like this:
erl -pa ./ebin ../../lib/some/path/ebin
The flags behaviour of erl is described here.
For more sophisticated path management you need to get familiar with how OTP release management is done (but I suspect that is a while away for you yet).

erlang - startup script

To start my program I do the next sequence:
$ erl
> c(module1).
> c(module2).
> c(modulen).
modulen:start().
Is there any possibility to create script that allow me to launch my program ?
You could use a loader script that takes care of starting your application in an OTP fashion:
-module(XYZ_app).
-export([start/0]).
start() ->
application:start(inets),
application:start(XYZ).
You launch that script through a shell script. Beware of using escript if you plan on building daemons running at the OS boot time as they are tricky.
#!/bin/bash
erl -boot start_sasl -s XYZ_app start
Of course you need your XYZ.app file (just an example):
{application, tinycouch,
[{description, "tinycouch"},
{vsn, "0.1"},
{modules, [
tinycouch, tinycouch_app, tinycouch_sup,
tinycouch_server, tinycouch_logger_h, tinycouch_utils,
tinycouch_db, mod_tinycouch
]},
{registered, [tinycouch
,tinycouch_server
,tinycouch_sup
]},
{applications, [kernel, stdlib, sasl, inets]},
{env, []},
%% Application Start point
{mod, {tinycouch_sup, []}}]}.
... and all your .erl files must have been compiled.
Note that if you intend to distribute your application (e.g. Debian repository etc), you probably should consider having a make file to compile and install your app.
As a final note: you could also go with a boot file (the ultimate OTP way) but I find those very constraining: a boot file ties your application to specific version release of Erlang (and other dependent applications). Your application might be able to run in various Erlang releases but you will need to have a separate build/release process for each "platform release" you intend to ship for.
You can compile the modules with erlc
erlc module1 module2 module3
You can also create a script to run you program
#!/usr/bin/escript
main(_) ->
modulen:start().
Then in the console:
chmod +x start.erl
./start.erl
Two ways
precompile your code
$ erlc module1.erl
$ erl -s module1 funcname arg1 arg2 ....
Or use escript
#!/usr/bin/env escript
main() ->
module1:fun(...)
escript is a scripting interface to Erlang
You can use erl -make directly, as it assumes all *.erl files should be compiled to *.beam, and skip it if they haven't been changed since last compile. Check out the make module for what you can put in your Emakefile to change certain behavior.
Using plain Makefile to invoke this compile strategy also gives other users a familiar build-procedure.
Having a bootstrap start function as jldupont suggests is a nice way to start up your development environment. It is even sufficiently fine for using in production to some point.
The next step is to use full OTP (*.rel) release files and generate boot scripts that starts all the applications in the order the *.app specify dependencies on each other.
In the home directory, create file
.erlang
in that file write
compile:file(/path-to/module1).
compile:file(/path-to/module2).
compile:file(/edit-real-path-to/modulen). % etcetera; do not use c(module) inside this file!
then, if you need add (inside .erlang):
module1:start(). % etc
When you run erl (in the shell), the content of the .erlang (provided this file is in the home dir) will be executed at start (of the interpreter-erlang-VM you launch).
You can create .erlang file in some other (some 'current') directory, then, if you run erl (erlang interpreter) in that directory, that another .erlang will override the content of that .erlang in the home dir (of that which is like /home/your-user-name/.erlang ).
It is good idea to write inside of .erlang some reminder, like
io:format(".erlang loaded-compiled module1!\n"). %etc
(as not to forget about that code which otherwise will be executed silently !)
(also, you can check, for this case, that e.g. module1 is indeed compiled and loaded after start, this or some similar way:
AllLoaded = code:all_loaded().
lists:filter(fun({Module,_})-> Module =:= module1 end, AllLoaded).
the answer should be like:
[{module1,"/home/your-user-name/(path-to-your-code)/module1.beam"}]
)
Check out Sinan and Faxien: http://www.erlware.org

Resources