plucky (1) escript.1.gz

Provided by: erlang-doc_27.2.4+dfsg-1_all bug

NAME

       escript - Run a script written in Erlang

SYNOPSIS

       script-name [arg1 arg2...]

DESCRIPTION

       escript  provides  support for running short Erlang programs without having to compile them first, and an
       easy way to retrieve the command-line arguments. escripts are created by either writing them by  hand  or
       using escript:create/2.

       escripts are run by directly invoking them (does not work on Windows):

              script-name [arg1 arg2...]

       or by calling the escript program (works on all platforms):

              escript [escript-flags] script-name.escript [arg1 arg2...]

       For 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 5

       The  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.

       NOTE: 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/0 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 compiled by the Erlang compiler.

       It  is  possible  to  force  it to be interpreted by including the following line somewhere in the script
       file:

              -mode(interpret).

       Execution of interpreted code is slower than compiled code, and some language constructs will  not  work,
       but there is no requirement for the Erlang compiler application to be available.

       CHANGE: Before Erlang/OTP 27 the script would be interpreted by default.

   Precompiled escripts
       A  script can also contains precompiled beam code. To create a precompiled escript it is recommended that
       you use escript:create/2. 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 escript and code.

       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

   Bundling escripts
       It is possible to bundle escript(s) with  an  Erlang  runtime  system  to  make  it  self-sufficient  and
       relocatable.  In  such  a standalone system, the escript(s) should be located in the top bin directory of
       the standalone system and given .escript as file extension. Further the (built-in) escript program should
       be  copied  to  the same directory and given the script's original name (without the .escript extension).
       This will enable use of the bundled Erlang runtime system.

       The (built-in) escript program first determines which Erlang runtime system to use and then starts it  to
       execute your script. Usually the runtime system is located in the same Erlang installation as the escript
       program itself. But for standalone systems with one or more escripts it may be the case that the  escript
       program  in  your  path actually starts the runtime system bundled with the escript. This is intentional,
       and typically happens when the standalone system bin directory is not in the execution path  (as  it  may
       cause  its erl program to override the desired one) and the escript(s) are referred to via symbolic links
       from a bin directory in the path.

   Options Accepted By escript
       -c
         Compiles the escript regardless of the value of the mode attribute.

       -d
         Debugs the escript. Starts the debugger, loads the module  containing  the  main/1  function  into  the
         debugger,  sets  a  breakpoint  in main/1, and invokes main/1. If the module is precompiled, it must be
         explicitly compiled with option debug_info.

       -i
         Interprets the escript regardless of the value of the mode attribute.

       -s
         Performs a syntactic and semantic check of the script file. Warnings and errors (if any) are written to
         the  standard  output,  but  the  script will not be run. The exit status is 0 if any errors are found,
         otherwise 127.

       NOTE: The configuration of the Erlang emulator invoked by  escript  can  also  be  controlled  using  the
       environment variables understood by erl.