erl

erl(1)                           User Commands                          erl(1)



NAME
       erl - The Erlang Emulator

DESCRIPTION
       The erl program starts an Erlang runtime system. The exact details (for
       example, whether erl is a script or a program and which other  programs
       it calls) are system-dependent.

       Windows  users  probably  wants  to use the werl program instead, which
       runs in its own window with scrollbars and supports command-line  edit‐
       ing.  The erl program on Windows provides no line editing in its shell,
       and on Windows 95 there is no way to scroll  back  to  text  which  has
       scrolled  off  the  screen.  The  erl program must be used, however, in
       pipelines or if you want to redirect standard input or output.

EXPORTS
       erl 

              Starts an Erlang runtime system.

              The arguments can be divided  into  emulator  flags,  flags  and
              plain arguments:


                * Any argument starting with the character + is interpreted as
                  an emulator flag. .br .br As indicated by the name, emulator
                  flags controls the behavior of the emulator. .br .br



                * Any  argument  starting  with  the  character  - (hyphen) is
                  interpreted as a flag which should be passed to  the  Erlang
                  part  of  the  runtime system, more specifically to the init
                  system process, see init(3erl). .br  .br  The  init  process
                  itself  interprets  some  of these flags, the init flags. It
                  also stores any remaining flags, the user flags. The  latter
                  can  be retrieved by calling init:get_argument/1. .br .br It
                  can be noted that there are a  small  number  of  "-"  flags
                  which  now  actually are emulator flags, see the description
                  below. .br .br



                * Plain arguments are not interpreted in  any  way.  They  are
                  also  stored  by  the  init  process and can be retrieved by
                  calling  init:get_plain_arguments/0.  Plain  arguments   can
                  occur  before  the first flag, or after a -- flag. Addition‐
                  ally, the flag -extra  causes  everything  that  follows  to
                  become plain arguments. .br .br




              Example:

              % erl +W w -sname arnie +R 9 -s my_init -extra +bertie
              (arnie@host)1> init:get_argument(sname).
              {ok,[["arnie"]]}
              (arnie@host)2> init:get_plain_arguments().
              ["+bertie"]


              Here  +W  w  and  +R 9 are emulator flags. -s my_init is an init
              flag, interpreted by init. -sname arnie is a user  flag,  stored
              by  init. It is read by Kernel and will cause the Erlang runtime
              system to become distributed. Finally, everything  after  -extra
              (that is, +bertie) is considered as plain arguments.

              % erl -myflag 1
              1> init:get_argument(myflag).
              {ok,[["1"]]}
              2> init:get_plain_arguments().
              []


              Here the user flag -myflag 1 is passed to and stored by the init
              process. It is a user defined flag, presumably used by some user
              defined application.


FLAGS
       In the following list, init flags are marked (init flag). Unless other‐
       wise specified, all other flags are user flags, for  which  the  values
       can  be retrieved by calling init:get_argument/1. Note that the list of
       user flags is not exhaustive, there may be additional, application spe‐
       cific  flags which instead are documented in the corresponding applica‐
       tion documentation.


          --(init flag)
             Everything following -- up to the next flag ( -flag or +flag)  is
             considered   plain   arguments   and   can   be  retrieved  using
             init:get_plain_arguments/0.



          -Application Par Val
             Sets the application configuration parameter Par to the value Val
             for   the   application  Application,  see  app(4)  and  applica‐
             tion(3erl).



          -args_file FileName
             Command line arguments are read from the file FileName. The argu‐
             ments  read from the file replace the ' -args_file FileName' flag
             on the resulting command line.

             The file FileName should be a plain text  file  and  may  contain
             comments  and  command  line arguments. A comment begins with a #
             character and continues until next end of line  character.  Back‐
             slash  (\)  is  used as quoting character. All command line argu‐
             ments accepted by erl are allowed, also the  -args_file  FileName
             flag. Be careful not to cause circular dependencies between files
             containing the -args_file flag, though.

             The -extra flag is treated specially. Its scope ends at  the  end
             of  the file. Arguments following an -extra flag are moved on the
             command line into the -extra section, i.e. the end of the command
             line following after an -extra flag.



          -async_shell_start
             The  initial Erlang shell does not read user input until the sys‐
             tem boot procedure has been completed  (Erlang  5.4  and  later).
             This flag disables the start synchronization feature and lets the
             shell start in parallel with the rest of the system.



          -boot File
             Specifies the name of the boot file, File.boot, which is used  to
             start  the  system. See init(3erl). Unless File contains an abso‐
             lute path, the system searches for File.boot in the  current  and
             $ROOT/bin directories.

             Defaults to $ROOT/bin/start.boot.



          -boot_var Var Dir
             If the boot script contains a path variable Var other than $ROOT,
             this variable is expanded to  Dir.  Used  when  applications  are
             installed   in   another   directory  than  $ROOT/lib,  see  sys‐
             tools:make_script/1,2.



          -code_path_cache
             Enables the code path cache of the code server, see code(3erl).



          -compile Mod1 Mod2 ...
             Compiles the specified modules and then terminates (with non-zero
             exit  code  if  the  compilation  of  some file did not succeed).
             Implies -noinput. Not recommended - use erlc instead.



          -config Config
             Specifies the name of a configuration file, Config.config,  which
             is  used  to  configure  applications.  See  app(4)  and applica‐
             tion(3erl).



          -connect_all false
             If this flag is present, global will not maintain  a  fully  con‐
             nected  network of distributed Erlang nodes, and then global name
             registration cannot be used. See global(3erl).



          -cookie Cookie
             Obsolete flag without any effect and common misspelling for -set‐
             cookie. Use -setcookie instead.



          -detached
             Starts  the  Erlang  runtime system detached from the system con‐
             sole. Useful for running daemons and backgrounds processes.



          -emu_args
             Useful for debugging. Prints out the actual arguments sent to the
             emulator.



          -env Variable Value
             Sets the host OS environment variable Variable to the value Value
             for the Erlang runtime system. Example:



             % erl -env DISPLAY gin:0
             In this example, an Erlang runtime system  is  started  with  the
             DISPLAY environment variable set to gin:0.



          -eval Expr(init flag)
             Makes init evaluate the expression Expr, see init(3erl).



          -extra(init flag)
             Everything following -extra is considered plain arguments and can
             be retrieved using init:get_plain_arguments/0.



          -heart
             Starts heart beat monitoring of the Erlang  runtime  system.  See
             heart(3erl).



          -hidden
             Starts  the  Erlang runtime system as a hidden node, if it is run
             as a distributed node. Hidden nodes always establish hidden  con‐
             nections  to  all other nodes except for nodes in the same global
             group. Hidden connections are not published  on  neither  of  the
             connected  nodes, i.e. neither of the connected nodes are part of
             the result from nodes/0 on the other node. See also hidden global
             groups, global_group(3erl).



          -hosts Hosts
             Specifies  the  IP  addresses  for the hosts on which Erlang boot
             servers are running,  see  erl_boot_server(3erl).  This  flag  is
             mandatory if the -loader inet flag is present.

             The IP addresses must be given in the standard form (four decimal
             numbers separated by periods, for example "150.236.20.74".  Hosts
             names  are  not  acceptable,  but a broadcast address (preferably
             limited to the local network) is.



          -id Id
             Specifies the identity of the Erlang runtime system. If it is run
             as  a distributed node, Id must be identical to the name supplied
             together with the -sname or -name flag.



          -init_debug
             Makes init write some debug information  while  interpreting  the
             boot script.



          -instr(emulator flag)
             Selects  an  instrumented Erlang runtime system (virtual machine)
             to run, instead of the ordinary one. When running an instrumented
             runtime system, some resource usage data can be obtained and ana‐
             lysed using  the  module  instrument.  Functionally,  it  behaves
             exactly like an ordinary Erlang runtime system.



          -loader Loader
             Specifies  the method used by erl_prim_loader to load Erlang mod‐
             ules into the system. See erl_prim_loader(3erl). Two Loader meth‐
             ods are supported, efile and inet. efile means use the local file
             system, this is the default. inet means  use  a  boot  server  on
             another machine, and the -id, -hosts and -setcookie flags must be
             specified as well. If Loader is something else, the user supplied
             Loader port program is started.



          -make
             Makes  the Erlang runtime system invoke make:all() in the current
             working directory and then  terminate.  See  make(3erl).  Implies
             -noinput.



          -man Module
             Displays  the manual page for the Erlang module Module. Only sup‐
             ported on Unix.



          -mode interactive | embedded
             Indicates if the system should load code dynamically  (  interac‐
             tive),  or if all code should be loaded during system initializa‐
             tion ( embedded), see code(3erl). Defaults to interactive.



          -name Name
             Makes the Erlang runtime system into  a  distributed  node.  This
             flag  invokes  all network servers necessary for a node to become
             distributed. See net_kernel(3erl). It is also ensured  that  epmd
             runs on the current host before Erlang is started. See epmd(1).

             The  name  of the node will be Name@Host, where Host is the fully
             qualified host name of the current host. For short names, use the
             -sname flag instead.



          -noinput
             Ensures  that  the  Erlang runtime system never tries to read any
             input. Implies -noshell.



          -noshell
             Starts an Erlang runtime system with no shell. This flag makes it
             possible  to  have  the Erlang runtime system as a component in a
             series of UNIX pipes.



          -nostick
             Disables the sticky directory facility of the Erlang code server,
             see code(3erl).



          -oldshell
             Invokes  the  old Erlang shell from Erlang 3.3. The old shell can
             still be used.



          -pa Dir1 Dir2 ...
             Adds the specified directories to the beginning of the code path,
             similar  to  code:add_pathsa/1. See code(3erl). As an alternative
             to -pa, if several directories are to be prepended  to  the  code
             and  the  directories have a common parent directory, that parent
             directory could be specified in the  ERL_LIBS  environment  vari‐
             able. See code(3erl).



          -pz Dir1 Dir2 ...
             Adds the specified directories to the end of the code path, simi‐
             lar to code:add_pathsz/1. See code(3erl).



          -remsh Node
             Starts Erlang with a remote shell connected to Node.



          -rsh Program
             Specifies an alternative to rsh for starting a slave  node  on  a
             remote host. See slave(3erl).



          -run 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
             strings. See init(3erl).



          -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(3erl).



          -setcookie Cookie
             Sets   the   magic   cookie   of   the   node   to   Cookie,  see
             erlang:set_cookie/2.



          -shutdown_time Time
             Specifies how long time (in milliseconds)  the  init  process  is
             allowed  to  spend  shutting  down  the  system.  If Time ms have
             elapsed, all processes still existing  are  killed.  Defaults  to
             infinity.



          -sname Name
             Makes  the Erlang runtime system into a distributed node, similar
             to -name, but the host name portion of the  node  name  Name@Host
             will be the short name, not fully qualified.

             This  is  sometimes the only way to run distributed Erlang if the
             DNS (Domain Name System) is not running. There can be no communi‐
             cation  between nodes running with the -sname flag and those run‐
             ning with the -name flag, as node names must be  unique  in  dis‐
             tributed Erlang systems.



          -smp [enable|auto|disable]
             -smp  enable  and  -smp starts the Erlang runtime system with SMP
             support enabled. This may fail if no runtime system with SMP sup‐
             port  is  available.  -smp  auto starts the Erlang runtime system
             with SMP support enabled if it is available  and  more  than  one
             logical  processor  are  detected.  -smp disable starts a runtime
             system without SMP support. By default -smp  auto  will  be  used
             unless a conflicting parameter has been passed, then -smp disable
             will be used. Currently only the -hybrid parameter conflicts with
             -smp auto.

             NOTE:  The  runtime system with SMP support will not be available
             on all supported platforms. See also the +S flag.



          -version(emulator flag)
             Makes the emulator print out its version number. The same as  erl
             +V.





EMULATOR FLAGS
       erl  invokes  the code for the Erlang emulator (virtual machine), which
       supports the following flags:


          +a size
             Suggested stack size, in kilowords, for  threads  in  the  async-
             thread  pool.  Valid range is 16-8192 kilowords. The default sug‐
             gested stack size is 16 kilowords, i.e,  64  kilobyte  on  32-bit
             architectures.  This small default size has been chosen since the
             amount of async-threads might be quite large. The default size is
             enough  for  drivers  delivered with Erlang/OTP, but might not be
             sufficiently large for other dynamically linked in  drivers  that
             use  the driver_async() functionality. Note that the value passed
             is only a suggestion, and it might even be ignored on some  plat‐
             forms.



          +A size
             Sets  the  number of threads in async thread pool, valid range is
             0-1024. Default is 0.



          +B [c | d | i]
             The c option makes Ctrl-C interrupt the current shell instead  of
             invoking the emulator break handler. The d option (same as speci‐
             fying +B without an extra option) disables the break handler. The
             i option makes the emulator ignore any break signal.

             If  the  c  option  is  used  with  oldshell on Unix, Ctrl-C will
             restart the shell process rather than interrupt it.

             Note that on Windows, this flag is only applicable for werl,  not
             erl  (  oldshell).  Note  also that Ctrl-Break is used instead of
             Ctrl-C on Windows.



          +c Disable compensation for sudden changes of system time.

             Normally,  erlang:now/0  will  not  immediately  reflect   sudden
             changes  in  the  system time, in order to keep timers (including
             receive-after)  working.  Instead,   the   time   maintained   by
             erlang:now/0  is  slowly  adjusted  towards  the new system time.
             (Slowly means in one percent adjustments; if the time is  off  by
             one minute, the time will be adjusted in 100 minutes.)

             When  the  +c option is given, this slow adjustment will not take
             place. Instead erlang:now/0 will always reflect the current  sys‐
             tem time. Note that timers are based on erlang:now/0. If the sys‐
             tem time jumps, timers then time out at the wrong time.



          +d If the emulator detects an internal error (or runs  out  of  mem‐
             ory),  it  will  by default generate both a crash dump and a core
             dump. The core dump will, however, not be very useful  since  the
             content  of  process heaps is destroyed by the crash dump genera‐
             tion.

             The +d option instructs the emulator to only produce a core  dump
             and no crash dump if an internal error is detected.

             Calling erlang:halt/1 with a string argument will still produce a
             crash dump.



          +h Size
             Sets the default heap size of processes to the size Size.



          +K true | false
             Enables or disables the kernel poll functionality if the emulator
             supports  it.  Default  is false (disabled). If the emulator does
             not support kernel poll, and the +K flag is passed to the  emula‐
             tor, a warning is issued at startup.



          +l Enables auto load tracing, displaying info while loading code.



          +MFlag Value
             Memory allocator specific flags, see erts_alloc(3erl) for further
             information.



          +P Number
             Sets the maximum number of concurrent processes for this  system.
             Number must be in the range 16..134217727. Default is 32768.



          +R ReleaseNumber
             Sets the compatibility mode.

             The   distribution  mechanism  is  not  backwards  compatible  by
             default. This flags sets the emulator in compatibility mode  with
             an  earlier  Erlang/OTP release ReleaseNumber. The release number
             must be in the range 7... This limits the emula‐
             tor,  making  it possible for it to communicate with Erlang nodes
             (as well as C- and Java nodes) running that earlier release.

             For example, an R10 node is not automatically compatible with  an
             R9  node,  but  R10 nodes started with the +R 9 flag can co-exist
             with R9 nodes in the same distributed  Erlang  system,  they  are
             R9-compatible.

             Note: Make sure all nodes (Erlang-, C-, and Java nodes) of a dis‐
             tributed Erlang system is of the same Erlang/OTP release, or from
             two different Erlang/OTP releases X and Y, where all Y nodes have
             compatibility mode X.

             For example: A distributed  Erlang  system  can  consist  of  R10
             nodes,  or of R9 nodes and R9-compatible R10 nodes, but not of R9
             nodes, R9-compatible R10 nodes and "regular" R10 nodes, as R9 and
             "regular" R10 nodes are not compatible.



          +r Force ets memory block to be moved on realloc.



          +S Schedulers:SchedulerOnline
             Sets  the  amount  of  scheduler  threads to create and scheduler
             threads to set online when SMP support has  been  enabled.  Valid
             range for both values are 1-1024. If the Erlang runtime system is
             able to determine the amount of logical processors configured and
             logical  processors available, Schedulers will default to logical
             processors configured, and SchedulersOnline will default to logi‐
             cal  processors  available; otherwise, the default values will be
             1. Schedulers may be omitted if :SchedulerOnline is not and  vice
             versa. The amount of schedulers online can be changed at run time
             via erlang:system_flag(schedulers_online, SchedulersOnline).

             This flag will be ignored if the emulator doesn't have  SMP  sup‐
             port enabled (see the -smp flag).



          +sFlag Value
             Scheduling specific flags.




           +sbt BindType
               Set scheduler bind type. Currently valid BindTypes:




              u  Same as erlang:system_flag(scheduler_bind_type, unbound).



              ns Same as erlang:system_flag(scheduler_bind_type, no_spread).



              ts Same        as        erlang:system_flag(scheduler_bind_type,
                 thread_spread).



              ps Same   as   erlang:system_flag(scheduler_bind_type,   proces‐
                 sor_spread).



              s  Same as erlang:system_flag(scheduler_bind_type, spread).



              nnts
                 Same        as        erlang:system_flag(scheduler_bind_type,
                 no_node_thread_spread).



              nnps
                 Same as erlang:system_flag(scheduler_bind_type,  no_node_pro‐
                 cessor_spread).



              tnnps
                 Same        as        erlang:system_flag(scheduler_bind_type,
                 thread_no_node_processor_spread).



              db Same        as        erlang:system_flag(scheduler_bind_type,
                 default_bind).


           Binding  of  schedulers are currently only supported on newer Linux
           and Solaris systems.

           If no CPU topology is available when the +sbt flag is processed and
           BindType  is any other type than u, the runtime system will fail to
           start. CPU topology can be defined using the +sct flag.  Note  that
           the  +sct  flag  may  have to be passed before the +sbt flag on the
           command line (in  case  no  CPU  topology  has  been  automatically
           detected).

           For  more  information, see erlang:system_flag(scheduler_bind_type,
           SchedulerBindType).



            +sct CpuTopology



             *  = integer(); when 0 =<  =< 65535



             *  = -



             *  =  | 



             *  = , | 



             *  = L



             *  = T | t



             *  = C | c



             *  = P | p



             *  = N | n



             *        =                      sorIds>         |                        eIds>



             * CpuTopology = : | 


           Upper-case letters signify real identifiers and lower-case  letters
           signify fake identifiers only used for description of the topology.
           Identifiers passed as real identifiers may be used by  the  runtime
           system  when trying to access specific hardware and if they are not
           correct the behavior is undefined. Faked  logical  CPU  identifiers
           are not accepted since there is no point in defining the CPU topol‐
           ogy without real logical CPU identifiers. Thread, core,  processor,
           and  node  identifiers  may  be  left  out.  If left out, thread id
           defaults to t0, core id defaults to c0, processor  id  defaults  to
           p0, and node id will be left undefined. Either each logical proces‐
           sor must belong to one and only one NUMA node, or no  logical  pro‐
           cessors must belong to any NUMA nodes.

           Both increasing and decreasing s are allowed.

           NUMA  node  identifiers are system wide. That is, each NUMA node on
           the system have to have a unique identifier. Processor  identifiers
           are  also  system wide. Core identifiers are processor wide. Thread
           identifiers are core wide.

           The order of the identifier types imply the hierarchy  of  the  CPU
           topology.  Valid  orders  are  either             eIds>,    or               eIds>.  That  is,  thread  is part of a core
           which is part of a processor which is  part  of  a  NUMA  node,  or
           thread is part of a core which is part of a NUMA node which is part
           of a processor. A cpu topology can consist of both processor exter‐
           nal, and processor internal NUMA nodes as long as each logical pro‐
           cessor belongs to one and only one NUMA node. If   is
           left  out,  its default position will be before . That is,
           the default is processor external NUMA nodes.

           If a list of identifiers is used in an :




             *  have to be a list of identifiers.



             * At least one other identifier type apart from  also
               have to have a list of identifiers.



             * All  lists  of  identifiers  have to produce the same amount of
               identifiers.


           A simple example. A single quad core  processor  may  be  described
           this way:



           % erl +sct L0-3c0-3
           1> erlang:system_info(cpu_topology).
           [{processor,[{core,{logical,0}},
                        {core,{logical,1}},
                        {core,{logical,2}},
                        {core,{logical,3}}]}]

           A  little  more complicated example. Two quad core processors. Each
           processor in its own NUMA node. The ordering of logical  processors
           is  a little weird. This in order to give a better example of iden‐
           tifier lists:



           % erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
           1> erlang:system_info(cpu_topology).
           [{node,[{processor,[{core,{logical,0}},
                               {core,{logical,1}},
                               {core,{logical,3}},
                               {core,{logical,2}}]}]},
            {node,[{processor,[{core,{logical,7}},
                               {core,{logical,4}},
                               {core,{logical,6}},
                               {core,{logical,5}}]}]}]

           As long as real identifiers are correct it is okay to  pass  a  CPU
           topology  that  is  not  a correct description of the CPU topology.
           When used with care this can actually be very useful. This in order
           to trick the emulator to bind its schedulers as you want. For exam‐
           ple, if you want to run multiple Erlang runtime systems on the same
           machine,  you  want  to  reduce  the  amount of schedulers used and
           manipulate the CPU topology so that they bind to different  logical
           CPUs.  An  example,  with two Erlang runtime systems on a quad core
           machine:



           % erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname one
           % erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname two

           In this example  each  runtime  system  have  two  schedulers  each
           online,  and  all schedulers online will run on different cores. If
           we change to one scheduler online on one runtime system, and  three
           schedulers  online  on  the other, all schedulers online will still
           run on different cores.

           Note that a faked CPU topology that does not reflect how  the  real
           CPU  topology  looks  like is likely to decrease the performance of
           the runtime system.

           For   more   information,   see    erlang:system_flag(cpu_topology,
           CpuTopology).




          +sss size
             Suggested  stack size, in kilowords, for scheduler threads. Valid
             range is 4-8192 kilowords. The default stack size  is  OS  depen‐
             dent.



          +T Level
             Enables  modified timing and sets the modified timing level. Cur‐
             rently valid range is 0-9. The timing of the runtime system  will
             change.  A  high  level usually means a greater change than a low
             level. Changing the timing can be very useful for finding  timing
             related bugs.

             Currently, modified timing affects the following:




           Process spawning
               A   process   calling   spawn,  spawn_link,  spawn_monitor,  or
               spawn_opt will be scheduled out  immediately  after  completing
               the  call.  When  higher  modified  timing levels are used, the
               caller will also sleep for a while after being scheduled out.



           Context reductions
               The amount of reductions a process is a allowed to
                          use before  being  scheduled  out  is  increased  or
               reduced.

           Input reductions
               The amount of reductions performed before checking I/O
                          is increased or reduced.
         NOTE:  Performance  will suffer when modified timing is enabled. This
         flag is only intended for  testing  and  debugging.  Also  note  that
         return_to and return_from trace messages will be lost when tracing on
         the spawn BIFs. This flag may be removed or changed at any time with‐
         out prior notice.



          +V Makes the emulator print out its version number.



          +v Verbose.



          +W w | i
             Sets  the  mapping of warning messages for error_logger. Messages
             sent to the error logger using one of the warning routines can be
             mapped  either  to  errors  (default),  warnings ( +W w), or info
             reports ( +W i). The  current  mapping  can  be  retrieved  using
             error_logger:warning_map/0.  See  error_logger(3erl)  for further
             information.





ENVIRONMENT VARIABLES
          ERL_CRASH_DUMP
             If the emulator needs to write a crash dump, the  value  of  this
             variable  will  be  the  file name of the crash dump file. If the
             variable is not set, the name of the  crash  dump  file  will  be
             erl_crash.dump in the current directory.



          ERL_CRASH_DUMP_NICE
             Unix  systems:  If  the  emulator needs to write a crash dump, it
             will use the value of this variable to set the nice value for the
             process,  thus  lowering  its  priority. The allowable range is 1
             through 39 (higher values will be replaced with 39). The  highest
             value, 39, will give the process the lowest priority.



          ERL_CRASH_DUMP_SECONDS
             Unix  systems: This variable gives the number of seconds that the
             emulator will be allowed to spend writing a crash dump. When  the
             given number of seconds have elapsed, the emulator will be termi‐
             nated by a SIGALRM signal.



          ERL_AFLAGS
             The content of this environment variable will  be  added  to  the
             beginning of the command line for erl.

             The  -extra  flag is treated specially. Its scope ends at the end
             of the  environment  variable  content.  Arguments  following  an
             -extra  flag  are  moved on the command line into the -extra sec‐
             tion, i.e. the end of the command line following after an  -extra
             flag.



          ERL_ZFLAGSand  ERL_FLAGS
             The  content  of these environment variables will be added to the
             end of the command line for erl.

             The -extra flag is treated specially. Its scope ends at  the  end
             of  the  environment  variable  content.  Arguments  following an
             -extra flag are moved on the command line into  the  -extra  sec‐
             tion,  i.e. the end of the command line following after an -extra
             flag.



          ERL_LIBS
             This environment variable contains a list of  additional  library
             directories that the code server will search for applications and
             add to the code path. See code(3erl).



          ERL_EPMD_PORT
             This environment variable can contain the port number to use when
             communicating  with epmd. The default port will work fine in most
             cases. A different port can be specified to allow nodes of  inde‐
             pendent  clusters  to  co-exist  on the same host. All nodes in a
             cluster must use the same epmd port number.





SEE ALSO
       init(3erl), erl_prim_loader(3erl),  erl_boot_server(3erl),  code(3erl),
       application(3erl),     heart(3erl),    net_kernel(3erl),    auth(3erl),
       make(3erl), epmd(1), erts_alloc(3erl)



Ericsson AB                       erts 5.7.4                            erl(1)