Provided by: erlang-base-hipe_14.b.4-dfsg-1ubuntu1_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.8 (OTP-R14A) the runtime system will by default  bind  schedulers  to
       logical  processors  using  the  default_bind bind type if the amount of schedulers are at
       least equal to the amount of logical  processors  configured,  binding  of  schedulers  is
       supported, and a CPU topology is available at startup.

       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.  If  this  is
       the  case  you,  are  are  advised  to  unbind the schedulers using the +sbtu command line
       argument, or by invoking erlang:system_flag(scheduler_bind_type, unbound).

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

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

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

           By enabling Unicode file name translation on systems where this is  not  default,  you
           open  up  to the possibility that some file names can not be interpreted by the VM and
           therefore will be returned to the program as raw binaries.  The  option  is  therefore
           considered experimental.

         +fna:
           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 filenames (use with care).

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

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

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

           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  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 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 bind schedulers to logical processors  using  the
             default_bind  bind type if the amount of schedulers are at least equal to the amount
             of logical processors configured, binding of schedulers  is  supported,  and  a  CPU
             topology is available at startup.

             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. If this is the case you, are advised to unbind the schedulers using
             the      +sbtu      command      line      argument,      or       by       invoking
             erlang:system_flag(scheduler_bind_type, unbound).

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

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

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

         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_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)