escript runs a script written in Erlang.
Example:
$ chmod u+x factorial $ cat factorial #!/usr/bin/env escript %% -*- erlang -*- %%! -sname factorial -mnesia debug verbose main([String]) -> try N = list_to_integer(String), F = fac(N), io:format("factorial ~w = ~w\n", [N,F]) catch _:_ -> usage() end; main(_) -> usage(). usage() -> io:format("usage: factorial integer\n"), halt(1). fac(0) -> 1; fac(N) -> N * fac(N-1). $ ./factorial 5 factorial 5 = 120 $ ./factorial usage: factorial integer $ ./factorial five usage: factorial integer
The header of the Erlang script in the example differs from a normal Erlang module. The first line is intended to be the interpreter line, which invokes escript.
However, if you invoke the escript as follows, the contents of the first line do not matter, but it cannot contain Erlang code as it will be ignored:
$ escript factorial 5The second line in the example contains an optional directive to the Emacs editor, which causes it to enter the major mode for editing Erlang source files. If the directive is present, it must be located on the second line.
If a comment selecting the encoding exists, it can be located on the second line.
The encoding specified by the above mentioned comment applies to the script itself. The encoding of the I/O-server, however, must be set explicitly as follows:
io:setopts([{encoding, latin1}])The default encoding of the I/O-server for standard_io is unicode if its supported. (see section Summary of Options) in the STDLIB User's Guide.
On the third line (or second line depending on the presence of the Emacs directive), arguments can be specified to the emulator, for example:
%%! -sname factorial -mnesia debug verbose
Such an argument line must start with %%! and the remaining line is interpreted as arguments to the emulator.
If you know the location of the escript executable, the first line can directly give the path to escript, for example:
#!/usr/local/bin/escript
As any other type of scripts, Erlang scripts do not work on Unix platforms if the execution bit for the script file is not set. (To turn on the execution bit, use chmod +x script-name.)
The remaining Erlang script file can either contain Erlang source code, an inlined beam file, or an inlined archive file.
An Erlang script file must always contain the main/1 function. When the script is run, the main/1 function is called with a list of strings representing the arguments specified to the script (not changed or interpreted in any way).
If the main/1 function in the script returns successfully, the exit status for the script is 0. If an exception is generated during execution, a short message is printed and the script terminates with exit status 127.
To return your own non-zero exit code, call halt(ExitCode), for example:
halt(1).
To retrieve the pathname of the script, call escript:script_name() from your script (the pathname is usually, but not always, absolute).
If the file contains source code (as in the example above), it is processed by the epp preprocessor. This means that you, for example, can use predefined macros (such as ?MODULE) and include directives like the -include_lib directive. For example, use
-include_lib("kernel/include/file.hrl").to include the record definitions for the records used by function file:read_link_info/1. You can also select encoding by including an encoding comment here, but if a valid encoding comment exists on the second line, it takes precedence.
The script is checked for syntactic and semantic correctness before it is run. If there are warnings (such as unused variables), they are printed and the script will still be run. If there are errors, they are printed and the script will not be run and its exit status is 127.
Both the module declaration and the export declaration of the main/1 function are optional.
By default, the script will be interpreted. You can force it to be compiled by including the following line somewhere in the script file:
-mode(compile).
Execution of interpreted code is slower than compiled code. If much of the execution takes place in interpreted code, it can be worthwhile to compile it, although the compilation itself takes a little while.
As mentioned earlier, a script can contains precompiled beam code. In a precompiled script, the interpretation of the script header is the same as in a script containing source code. This means that you can make a beam file executable by prepending the file with the lines starting with #! and %%! mentioned above. In a precompiled script, the main/1 function must be exported.
Another option is to have an entire Erlang archive in the script. In an archive script, the interpretation of the script header is the same as in a script containing source code. This means that you can make an archive file executable by prepending the file with the lines starting with #! and %%! mentioned above. In an archive script, the main/1 function must be exported. By default the main/1 function in the module with the same name as the basename of the escript file is invoked. This behavior can be overridden by setting flag -escript main Module as one of the emulator flags. Module must be the name of a module that has an exported main/1 function. For more information about archives and code loading, see code(3).
It is often very convenient to have a header in the escript, especially on Unix platforms. However, the header is optional, so you directly can "execute" an Erlang module, Beam file, or archive file without adding any header to them. But then you have to invoke the script as follows:
$ escript factorial.erl 5 factorial 5 = 120 $ escript factorial.beam 5 factorial 5 = 120 $ escript factorial.zip 5 factorial 5 = 120