Provided by: erlang-base_16.b.3-dfsg-1ubuntu2_amd64 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.

   Note:
       As of ERTS version 5.9 (OTP-R15B) the runtime system will by default not  bind  schedulers
       to logical processors. For more information see documentation of the +sbt system flag.

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.

                  As indicated by the name, emulator flags controls the behavior of the emulator.

                * 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).

                  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.

                  It  can  be noted that there are a small number of "-" flags which now actually
                  are emulator flags, see the description below.

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

              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(5) 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(5) 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. Implies -noinput.

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

           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.  If  thread
           support is available, the default is 10.

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

         +e Number:
           Set max number of ETS tables.

         +ec:
           Force the compressed option on all ETS tables. Only intended for test and evaluation.

         +fnl:
           The VM works with file names as if they are encoded using  the  ISO-latin-1  encoding,
           disallowing  Unicode  characters  with  codepoints  beyond  255.  This  is  default on
           operating systems that have transparent file naming, i.e. all Unixes except MacOSX.

           See STDLIB User's Guide for more infomation about unicode file names.

         +fnu[{w|i|e}]:
           The VM works with file names as if they are encoded using UTF-8 (or some other  system
           specific  Unicode  encoding).  This  is  the default on operating systems that enforce
           Unicode encoding, i.e. Windows and MacOSX.

           The +fnu switch can be followed by w, i, or e to control the way wrongly encoded  file
           names  are to be reported. w means that a warning is sent to the error_logger whenever
           a wrongly encoded file name is "skipped" in directory listings,  i  means  that  those
           wrongly encoded file names are silently ignored and e means that the API function will
           return an error whenever a wrongly encoded file (or directory) name is encountered.  w
           is  the  default.  Note  that file:read_link/1 will always return an error if the link
           points to an invalid file name.

           See STDLIB User's Guide for more infomation about unicode file names.

         +fna[{w|i|e}]:
           Selection between +fnl and +fnu is done based on the current locale  settings  in  the
           OS,  meaning  that if you have set your terminal for UTF-8 encoding, the filesystem is
           expected to use the same encoding for file names (use with care).

           The +fna switch can be followed by w, i, or e. This will have  effect  if  the  locale
           settings cause the behavior of +fnu to be selected. See the description of +fnu above.
           If the locale settings cause the behavior of +fnl to be selected, then w, i, or e will
           not have any effect.

           See STDLIB User's Guide for more infomation about unicode file names.

         +hms Size:
           Sets the default heap size of processes to the size Size.

         +hmbs Size:
           Sets the default binary virtual 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.

         +L:
           Don't  load  information about source file names and line numbers. This will save some
           memory, but exceptions will not contain information about  the  file  names  and  line
           numbers.

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

         +n Behavior:
           Control behavior of signals to ports.

           As  of  OTP-R16 signals to ports are truly asynchronously delivered. Note that signals
           always have been  documented  as  asynchronous.  The  underlying  implementation  has,
           however,  previously  delivered  these signals synchronously. Correctly written Erlang
           programs should be able to handle this without any issues.  Bugs  in  existing  Erlang
           programs that make false assumptions about signals to ports may, however, be tricky to
           find. This switch has been introduced in order to at least make it easier  to  compare
           behaviors  during  a  transition  period.  Note that this flag is deprecated as of its
           introduction, and is scheduled for removal in OTP-R17. Behavior should be one  of  the
           following characters:

           d:
             The  default.  Asynchronous  signals.  A  process  that sends a signal to a port may
             continue execution before the signal has been delivered to the port.

           s:
             Synchronous signals. A processes that sends a signal to a  port  will  not  continue
             execution  until  the signal has been delivered. Should only be used for testing and
             debugging.

           a:
             Asynchronous signals. As the default, but a processes that sends a signal will  even
             more frequently continue execution before the signal has been delivered to the port.
             Should only be used for testing and debugging.

         +pc Range:
           Sets the range of characters that the system  will  consider  printable  in  heuristic
           detection  of  strings.  This  typically  affects  the  shell,  debugger and io:format
           functions (when ~tp is used in the format string).

           Currently two values for the Range are supported:

             latin1:
               The default. Only characters in the ISO-latin-1 range can be considered printable,
               which  means  that  a  character  with a code point > 255 will never be considered
               printable and that lists containing such characters will be displayed as lists  of
               integers rather than text strings by tools.

             unicode:
               All  printable  Unicode  characters  are  considered when determining if a list of
               integers is to be displayed in string syntax. This may give unexpected results  if
               for example your font does not cover all Unicode characters.

           Se also  io:printable_range/0.

         +P Number|legacy:
           Sets  the  maximum  number  of  simultaneously existing processes for this system if a
           Number is passed as value. Valid range for Number is [1024-134217727]

           NOTE: The actual maximum chosen may be much larger than the Number  passed.  Currently
           the  runtime  system often, but not always, chooses a value that is a power of 2. This
           might, however, be changed in the future. The actual value chosen can  be  checked  by
           calling erlang:system_info(process_limit).

           The default value is 262144

           If  legacy  is  passed  as  value,  the  legacy  algorithm  for  allocation of process
           identifiers will be used. Using the legacy algorithm, identifiers will be allocated in
           a strictly increasing fashion until largest possible identifier has been reached. Note
           that  this  algorithm  suffers  from  performance  issues  and   can   under   certain
           circumstances  be  extremely  expensive.  The  legacy  algoritm is deprecated, and the
           legacy option is scheduled for removal in OTP-R18.

         +Q Number|legacy:
           Sets the maximum number of simultaneously existing ports for this system if  a  Number
           is passed as value. Valid range for Number is [1024-134217727]

           NOTE:  The  actual  maximum  chosen  may be much larger than the actual Number passed.
           Currently the runtime system often, but not always, chooses a value that is a power of
           2.  This  might,  however,  be  changed  in the future. The actual value chosen can be
           checked by calling erlang:system_info(port_limit).

           The default value used is normally 65536. However, if the runtime system  is  able  to
           determine maximum amount of file descriptors that it is allowed to open and this value
           is larger than 65536, the chosen value will increased to a value larger  or  equal  to
           the maximum amount of file descriptors that can be opened.

           On  Windows the default value is set to 8196 because the normal OS limitations are set
           higher than most machines can handle.

           Previously the environment variable ERL_MAX_PORTS was used  for  setting  the  maximum
           number  of simultaneously existing ports. This environment variable is deprecated, and
           scheduled for removal in OTP-R17, but can still be used.

           If legacy is passed as value, the legacy algorithm for allocation of port  identifiers
           will  be used. Using the legacy algorithm, identifiers will be allocated in a strictly
           increasing fashion until largest possible identifier has been reached. Note that  this
           algorithm  suffers  from  performance  issues  and  can under certain circumstances be
           extremely expensive. The legacy algoritm is  deprecated,  and  the  legacy  option  is
           scheduled for removal in OTP-R18.

         +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 <current release>-2..<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.

           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.

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

         +rg ReaderGroupsLimit:
           Limits  the  amount  of  reader  groups  used  by  read/write locks optimized for read
           operations in the Erlang runtime system. By default the reader groups limit equals 64.

           When the amount of schedulers is less than or equal to the reader groups  limit,  each
           scheduler  has  its own reader group. When the amount of schedulers is larger than the
           reader groups limit, schedulers share reader groups.  Shared  reader  groups  degrades
           read  lock  and read unlock performance while a large amount of reader groups degrades
           write lock performance, so the limit  is  a  tradeoff  between  performance  for  read
           operations  and performance for write operations. Each reader group currently consumes
           64 byte in each read/write lock. Also note that a runtime system using  shared  reader
           groups benefits from binding schedulers to logical processors, since the reader groups
           are distributed better between schedulers.

         +S Schedulers:SchedulerOnline:
           Sets the number of scheduler threads to create and scheduler  threads  to  set  online
           when  SMP support has been enabled. The maximum for both values is 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 number of schedulers online can be changed at run time  via
           erlang:system_flag(schedulers_online, SchedulersOnline).

           If  Schedulers  or  SchedulersOnline  is  specified as a negative number, the value is
           subtracted from the  default  number  of  logical  processors  configured  or  logical
           processors available, respectively.

           Specifying  the  value  0  for  Schedulers  or  SchedulersOnline  resets the number of
           scheduler threads or scheduler threads online respectively to its default value.

           This option is ignored if the emulator doesn't have SMP support enabled (see the  -smp
           flag).

         +SP SchedulersPercentage:SchedulersOnlinePercentage:
           Similar  to  +S but uses percentages to set the number of scheduler threads to create,
           based on logical processors configured, and scheduler threads to set online, based  on
           logical processors available, when SMP support has been enabled. Specified values must
           be greater than 0. For example, +SP 50:25 sets the number of scheduler threads to  50%
           of the logical processors configured and the number of scheduler threads online to 25%
           of  the  logical  processors  available.  SchedulersPercentage  may  be   omitted   if
           :SchedulersOnlinePercentage is not and vice versa. The number of schedulers online can
           be changed at run time via erlang:system_flag(schedulers_online, SchedulersOnline).

           This option interacts with +S settings. For example, on a system with 8 logical  cores
           configured  and  8  logical cores available, the combination of the options +S 4:4 +SP
           50:25 (in either order) results in 2 scheduler threads (50%  of  4)  and  1  scheduler
           thread online (25% of 4).

           This  option is 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.

             Schedulers can also be bound using the +stbt flag. The only difference between these
             two flags is how the following errors are handled:

             * Binding of schedulers is not supported on the specific platform.

             * No   available  CPU  topology.  That  is  the  runtime  system  was  not  able  to
               automatically detected the CPU topology, and no user defined CPU topology was set.

             If any of these errors occur when +sbt has been  passed,  the  runtime  system  will
             print an error message, and refuse to start. If any of these errors occur when +stbt
             has been passed, the runtime system will silently ignore the  error,  and  start  up
             using unbound schedulers.

             Currently valid BindTypes:

             u:
               unbound  - Schedulers will not be bound to logical processors, i.e., the operating
               system decides where the scheduler threads execute, and when to migrate them. This
               is the default.

             ns:
               no_spread  - Schedulers with close scheduler identifiers will be bound as close as
               possible in hardware.

             ts:
               thread_spread - Thread refers to hardware threads  (e.g.  Intel's  hyper-threads).
               Schedulers  with  low  scheduler  identifiers, will be bound to the first hardware
               thread of each core, then schedulers with higher  scheduler  identifiers  will  be
               bound to the second hardware thread of each core, etc.

             ps:
               processor_spread  -  Schedulers  will  be spread like thread_spread, but also over
               physical processor chips.

             s:
               spread - Schedulers will be spread as much as possible.

             nnts:
               no_node_thread_spread - Like thread_spread,  but  if  multiple  NUMA  (Non-Uniform
               Memory  Access)  nodes  exists,  schedulers will be spread over one NUMA node at a
               time, i.e., all logical processors of one NUMA node will be bound to schedulers in
               sequence.

             nnps:
               no_node_processor_spread  -  Like  processor_spread,  but  if  multiple NUMA nodes
               exists, schedulers will be spread over one NUMA node at a time, i.e., all  logical
               processors of one NUMA node will be bound to schedulers in sequence.

             tnnps:
               thread_no_node_processor_spread    -   A   combination   of   thread_spread,   and
               no_node_processor_spread. Schedulers will be spread over hardware  threads  across
               NUMA  nodes,  but schedulers will only be spread over processors internally in one
               NUMA node at a time.

             db:
               default_bind -  Binds  schedulers  the  default  way.  Currently  the  default  is
               thread_no_node_processor_spread (which might change in the future).

             Binding  of schedulers is currently only supported on newer Linux, Solaris, FreeBSD,
             and Windows 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).

             The runtime system will by default not bind schedulers to logical processors.

             NOTE: If the Erlang runtime system is the only operating system process  that  binds
             threads  to logical processors, this improves the performance of the runtime system.
             However, if other operating system processes (as for example another Erlang  runtime
             system)  also  bind  threads  to  logical  processors,  there might be a performance
             penalty instead. In some cases this performance penalty might be severe. If this  is
             the case, you are advised to not bind the schedulers.

             How  schedulers  are  bound matters. For example, in situations when there are fewer
             running processes than schedulers  online,  the  runtime  system  tries  to  migrate
             processes  to schedulers with low scheduler identifiers. The more the schedulers are
             spread over the hardware, the more resources will be available to the runtime system
             in such situations.

             NOTE:  If a scheduler fails to bind, this will often be silently ignored. This since
             it isn't always possible to verify valid logical processor identifiers. If an  error
             is reported, it will be reported to the error_logger. If you want to verify that the
             schedulers      actually       have       bound       as       requested,       call
             erlang:system_info(scheduler_bindings).

           +sbwt none|very_short|short|medium|long|very_long:
             Set  scheduler  busy wait threshold. Default is medium. The threshold determines how
             long schedulers should busy wait when running out of work before going to sleep.

             NOTE: This flag may be removed or changed at any time without prior notice.

           +scl true|false:
             Enable or disable scheduler compaction of load. By default scheduler  compaction  of
             load  is  enabled.  When enabled, load balancing will strive for a load distribution
             which causes as many scheduler threads as possible to be fully loaded (i.e., not run
             out  of work). This is accomplished by migrating load (e.g. runnable processes) into
             a smaller set of schedulers  when  schedulers  frequently  run  out  of  work.  When
             disabled, the frequency with which schedulers run out of work will not be taken into
             account by the load balancing logic.

           +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>

             Set  a  user  defined  CPU topology. The user defined CPU topology will override any
             automatically  detected  CPU  topology.  The  CPU  topology  is  used  when  binding
             schedulers to logical processors.

             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_info(cpu_topology).

           +sfwi Interval:
             Set  scheduler  forced wakeup interval. All run queues will be scanned each Interval
             milliseconds. While there are sleeping schedulers in the system, one scheduler  will
             be  woken  for  each  non-empty  run  queue found. An Interval of zero disables this
             feature, which also is the default.

             This feature has been introduced as a temporary  workaround  for  lengthy  executing
             native code, and native code that do not bump reductions properly in OTP. When these
             bugs have be fixed the +sfwi flag will be removed.

           +stbt BindType:
             Try to set scheduler bind type. The same as the +sbt flag with the exception of  how
             some  errors  are  handled.  For more information, see the documentation of the +sbt
             flag.

           +sws very_eager|eager|medium|lazy|very_lazy:
             Set scheduler wake cleanup threshold. Default is  medium.  This  flag  controls  how
             eager  schedulers  should  be  requesting wake up due to certain cleanup operations.
             When a lazy setting is used, more outstanding cleanup operations can be left  undone
             while  a  scheduler  is  idling. When an eager setting is used, schedulers will more
             frequently be woken, potentially increasing CPU-utilization.

             NOTE: This flag may be removed or changed at any time without prior notice.

           +sws default|legacy:
             Set scheduler wakeup strategy. Default strategy changed in erts-5.10/OTP-R16A.  This
             strategy  was  previously known as proposal in OTP-R15. The legacy strategy was used
             as default from R13 up to and including R15.

             NOTE: This flag may be removed or changed at any time without prior notice.

           +swt very_low|low|medium|high|very_high:
             Set scheduler wakeup threshold. Default is medium. The threshold determines when  to
             wake  up  sleeping  schedulers when more work than can be handled by currently awake
             schedulers exist. A low threshold will cause earlier wakeups, and a  high  threshold
             will  cause  later  wakeups.  Early  wakeups  will  distribute  work  over  multiple
             schedulers faster, but work will more easily bounce between schedulers.

             NOTE: This flag may be removed or changed at any time without prior notice.

           +spp Bool:
             Set default scheduler hint for port  parallelism.  If  set  to  true,  the  VM  will
             schedule  port  tasks  when it by this can improve the parallelism in the system. If
             set to false, the VM will try to perform port tasks immediately and by this  improve
             latency at the expense of parallelism. If this flag has not been passed, the default
             scheduler hint for port parallelism is currently false.  The  default  used  can  be
             inspected  in  runtime  by calling erlang:system_info(port_parallelism). The default
             can be overriden on port creation by passing the parallelism option to open_port/2.

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

         +t size:
           Set the maximum number of atoms the VM can handle. Default is 1048576.

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

         +zFlag Value:
           Miscellaneous flags.

           +zdbbl size:
             Set  the  distribution  buffer  busy limit (dist_buf_busy_limit) in kilobytes. Valid
             range is 1-2097151. Default is 1024.

             A larger buffer limit will allow processes to buffer more outgoing messages over the
             distribution.  When  the  buffer  limit  has been reached, sending processes will be
             suspended until the buffer size has shrunk. The buffer  limit  is  per  distribution
             channel. A higher limit will give lower latency and higher throughput at the expense
             of higher memory usage.

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.

           If   the   environment   variable   is   not  set  or  it  is  set  to  zero  seconds,
           ERL_CRASH_DUMP_SECONDS=0, the runtime system will not even attempt to write the  crash
           dump file. It will just terminate.

           If  the environment variable is set to negative valie, e.g. ERL_CRASH_DUMP_SECONDS=-1,
           the runtime system will wait indefinitely for the crash dump file to be written.

           This environment variable is used in conjuction with heart if heart is running:

           ERL_CRASH_DUMP_SECONDS=0:
             Suppresses the writing a crash dump file entirely, thus rebooting the runtime system
             immediately. This is the same as not setting the environment variable.

           ERL_CRASH_DUMP_SECONDS=-1:
             Setting  the  environment variable to a negative value will cause the termination of
             the runtime system to wait until the crash dump file has been completly written.

           ERL_CRASH_DUMP_SECONDS=S:
             Will wait for S seconds to complete the crash  dump  file  and  then  terminate  the
             runtime system.

         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_ZFLAGS and 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_ADDRESS:
           This environment variable may be set to a comma-separated list  of  IP  addresses,  in
           which  case  the  epmd daemon will listen only on the specified address(es) and on the
           loopback address (which is implicitly added to the list if it has not been specified).

         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.

CONFIGURATION

       The  standard  Erlang/OTP  system  can  be re-configured to change the default behavior on
       start-up.

         The .erlang Start-up File:
           When Erlang/OTP is started, the system searches  for  a  file  named  .erlang  in  the
           directory  where  Erlang/OTP  is  started.  If not found, the user's home directory is
           searched for an .erlang file.

           If an .erlang file is found, it is assumed to contain valid Erlang expressions.  These
           expressions are evaluated as if they were input to the shell.

           A typical .erlang file contains a set of search paths, for example:

                 io:format("executing user profile in HOME/.erlang\n",[]).
                 code:add_path("/home/calvin/test/ebin").
                 code:add_path("/home/hobbes/bigappl-1.2/ebin").
                 io:format(".erlang rc finished\n",[]).

         user_default and shell_default:
           Functions  in  the  shell  which  are  not prefixed by a module name are assumed to be
           functional objects  (Funs),  built-in  functions  (BIFs),  or  belong  to  the  module
           user_default or shell_default.

           To  include  private  shell commands, define them in a module user_default and add the
           following argument as the first line in the .erlang file.

                  code:load_abs("..../user_default").

         erl:
           If the contents of .erlang are changed  and  a  private  version  of  user_default  is
           defined, it is possible to customize the Erlang/OTP environment. More powerful changes
           can be made by supplying command line arguments in the start-up script erl.  Refer  to
           erl(1) and init(3erl) for further information.

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)