Provided by: erlang-base-hipe_13.b.3-dfsg-2ubuntu3_i386 bug

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
       editing.  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 <arguments>

              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.
                  Additionally, 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
       otherwise 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   specific  flags  which  instead  are  documented  in  the
       corresponding application 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
             application(3erl).

          -args_file FileName
             Command line arguments are  read  from  the  file  FileName.  The
             arguments  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.
             Backslash  (\)  is  used  as  quoting character. All command line
             arguments 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
             system 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
             absolute 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
             systools: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
             application(3erl).

          -connect_all false
             If this flag  is  present,  global  will  not  maintain  a  fully
             connected  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
             -setcookie. Use -setcookie instead.

          -detached
             Starts  the  Erlang  runtime  system  detached  from  the  system
             console. 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
             connections  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
             analysed 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
             modules into the system. See  erl_prim_loader(3erl).  Two  Loader
             methods  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
             supported on Unix.

          -mode interactive | embedded
             Indicates  if  the  system  should  load   code   dynamically   (
             interactive),  or  if  all  code  should  be loaded during system
             initialization  (  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
             variable. See code(3erl).

          -pz Dir1 Dir2 ...
             Adds the specified directories to  the  end  of  the  code  path,
             similar 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
             communication between nodes running  with  the  -sname  flag  and
             those  running  with the -name flag, as node names must be unique
             in distributed 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
             support 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
             suggested  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
             platforms.

          +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
             specifying  +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
             system time. Note that timers are based on erlang:now/0.  If  the
             system time jumps, timers then time out at the wrong time.

          +d If  the  emulator  detects  an  internal  error  (or  runs out of
             memory), 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
             generation.

             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
             emulator, 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..<current  release>.  This limits the
             emulator, 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
             distributed 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
             logical  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
             support 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,
                 processor_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_processor_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

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

             * <IdRange> = <Id>-<Id>

             * <IdOrIdRange> = <Id> | <IdRange>

             * <IdList> = <IdOrIdRange>,<IdOrIdRange> | <IdOrIdRange>

             * <LogicalIds> = L<IdList>

             * <ThreadIds> = T<IdList> | t<IdList>

             * <CoreIds> = C<IdList> | c<IdList>

             * <ProcessorIds> = P<IdList> | p<IdList>

             * <NodeIds> = N<IdList> | n<IdList>

             * <IdDefs>                                                      =
               <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>       |
               <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>

             * CpuTopology = <IdDefs>:<IdDefs> | <IdDefs>

           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
           topology  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 processor must belong to one and only one NUMA node, or  no
           logical processors must belong to any NUMA nodes.

           Both increasing and decreasing <IdRange>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
           <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>,         or
           <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>.  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 external, and processor internal NUMA nodes as long
           as each logical processor belongs to one and only one NUMA node. If
           <ProcessorIds>  is  left  out,  its default position will be before
           <NodeIds>. That is, the default is processor external NUMA nodes.

           If a list of identifiers is used in an <IdDefs>:

             * <LogicalIds> have to be a list of identifiers.

             * At least one other identifier type apart from <LogicalIds> 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
           identifier 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
           example, 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
             dependent.

          +T Level
             Enables  modified  timing  and  sets  the  modified timing level.
             Currently 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
         without 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
             terminated 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
             section, 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
             section,  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
             independent 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)