Go to main content

man pages section 1: User Commands

Exit Print View

Updated: Wednesday, February 10, 2021
 
 

erl (1)

Name

erl - The Erlang emulator.

Synopsis

Please see following description for synopsis

Description

erl(1)                           User Commands                          erl(1)



NAME
       erl - The Erlang emulator.

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

       Windows users probably want 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 that 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 from ERTS 5.9 (Erlang/OTP R15B) the runtime system does  by  default
       not  bind  schedulers  to logical processors. For more information, see
       system flag +sbt.


EXPORTS
       erl <arguments>

              Starts an Erlang runtime system.

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

                * Any  argument starting with character + is interpreted as an
                  emulator flag.

                  As indicated by the name, emulator flags control the  behav-
                  ior of the emulator.

                * Any  argument  starting  with character - (hyphen) is inter-
                  preted as a flag, which is to be passed to the  Erlang  part
                  of  the runtime system, more specifically to the init system
                  process, see init(3).

                  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_argu-
                  ment/1.

                  A  small  number  of "-" flags exist, 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. Also, the
                  -extra flag causes everything that follows to  become  plain
                  arguments.

              Examples:

              % 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 causes the Erlang runtime sys-
              tem 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 oth-
       erwise specified, all other flags are user flags, for which the  values
       can  be  retrieved by calling init:get_argument/1. Notice that the list
       of user flags is not exhaustive, there can be more application-specific
       flags that instead are described in the corresponding application docu-
       mentation.

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

         -Application Par Val:
           Sets the application configuration parameter Par to the  value  Val
           for the application Application; see app(4) and application(3).

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

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

           The  flag  -extra  is treated in special way. Its scope ends at the
           end of the file. Arguments following an -extra flag  are  moved  on
           the  command  line into the -extra section, that is, 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/OTP 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(3). 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   sys-
           tools:make_script/1,2 in SASL.

         -code_path_cache:
           Enables the code path cache of the code server; see code(3).

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

           Not recommended; use erlc instead.

         -config Config:
           Specifies the name of a configuration file, Config.config, which is
           used to configure applications; see app(4) and application(3).

         -connect_all false:
           If this flag is present, global does not maintain a fully connected
           network of distributed Erlang nodes, and then global name registra-
           tion cannot be used; see global(3).

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

         -detached:
           Starts  the Erlang runtime system detached from the system console.
           Useful for  running  daemons  and  backgrounds  processes.  Implies
           -noinput.

         -emu_args:
           Useful for debugging. Prints the 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  environ-
           ment variable DISPLAY set to gin:0.

         -epmd_module Module (init flag):
           Configures  the module responsible to communicate to epmd. Defaults
           to erl_epmd.

         -eval Expr (init flag):
           Makes init evaluate the expression Expr; see init(3).

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

         -heart:
           Starts  heartbeat  monitoring  of  the  Erlang  runtime system; see
           heart(3).

         -hidden:
           Starts the Erlang runtime system as a hidden node, if it is run  as
           a  distributed  node.  Hidden nodes always establish hidden connec-
           tions to all other nodes except for nodes in the same global group.
           Hidden connections are not published on any of the connected nodes,
           that is, none of the connected nodes are part of  the  result  from
           nodes/0   on  the  other  node.  See  also  hidden  global  groups;
           global_group(3).

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

           The IP addresses must be specified in the standard form (four deci-
           mal  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 flag -sname or -name.

         -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 run-
           time system, some resource usage data can be obtained and  analyzed
           using  the instrument module. 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(3). Two Loader methods are
           supported:

           * efile, which means  use  the  local  file  system,  this  is  the
             default.

           * inet, which means use a boot server on another machine. The flags
             -id, -hosts and -setcookie must also be specified.

           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(3).  Implies  -noin-
           put.

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

         -mode interactive | embedded:
           Indicates if the system is to load code dynamically  (interactive),
           or if all code is to be loaded during system initialization (embed-
           ded); see code(3). 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 distrib-
           uted; see net_kernel(3). It is also ensured that epmd runs  on  the
           current   host  before  Erlang  is  started;  see  epmd(1).and  the
           -start_epmd option.

           The node name will be Name@Host, where Host is the fully  qualified
           host  name  of  the  current host. For short names, use flag -sname
           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(3).

         -oldshell:
           Invokes the old Erlang shell from Erlang/OTP 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. Note that  the  order  of  the  given
           directories will be reversed in the resulting path.

           As  an  alternative  to  -pa,  if  several  directories  are  to be
           prepended to the code path and the directories have a common parent
           directory,  that  parent  directory can be specified in environment
           variable ERL_LIBS; see code(3).

         -pz Dir1 Dir2 ...:
           Adds the specified directories to the end of the code path, similar
           to code:add_pathsz/1; see code(3).

         -path Dir1 Dir2 ...:
           Replaces the path specified in the boot script; see script(4).

         -proto_dist Proto:
           Specifies a protocol for Erlang distribution:

           inet_tcp:
             TCP over IPv4 (the default)

           inet_tls:
             Distribution over TLS/SSL

           inet6_tcp:
             TCP over IPv6

           For example, to start up IPv6 distributed nodes:

         % erl -name test@ipv6node.example.com -proto_dist inet6_tcp

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

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

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

         -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  milliseconds
           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
           Domain Name System (DNS) is not running. No communication can exist
           between nodes running with flag -sname and those running with  flag
           -name, as node names must be unique in distributed Erlang systems.

         -start_epmd true | false:
           Specifies  whether  Erlang should start epmd on startup. By default
           this is true, but if you prefer to start epmd manually, set this to
           false.

           This  only applies if Erlang is started as a distributed node, i.e.
           if -name or -sname is specified. Otherwise,  epmd  is  not  started
           even if -start_epmd true is given.

           Note that a distributed node will fail to start if epmd is not run-
           ning.

         -smp [enable|auto|disable]:
           -smp enable and -smp start the Erlang runtime system with SMP  sup-
           port  enabled.  This can 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 pro-
           cessor is detected. -smp disable starts a  runtime  system  without
           SMP support.

     Note:
         The runtime system with SMP support is not available on all supported
         platforms. See also flag +S.


         -version (emulator flag):
           Makes the emulator print 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, that is, 64 kilobyte on 32-bit architectures.
           This small default size has been chosen because the number of async
           threads can be large. The default size is enough for drivers deliv-
           ered with Erlang/OTP, but might  not  be  large  enough  for  other
           dynamically linked-in drivers that use the driver_async() function-
           ality. Notice that the value passed is only a  suggestion,  and  it
           can even be ignored on some platforms.

         +A size:
           Sets  the  number  of  threads in async thread pool. Valid range is
           0-1024. Defaults to 10 if thread support is available.

         +B [c | d | i]:
           Option c makes Ctrl-C interrupt the current shell instead of invok-
           ing  the  emulator  break  handler. Option d (same as specifying +B
           without an extra option) disables the break handler. Option i makes
           the emulator ignore any break signal.

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

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

         +c true | false:
           Enables or disables time correction:

           true:
             Enables time correction. This is the default if  time  correction
             is supported on the specific platform.

           false:
             Disables time correction.

           For  backward compatibility, the boolean value can be omitted. This
           is interpreted as +c false.

         +C no_time_warp | single_time_warp | multi_time_warp:
           Sets time warp mode:

           no_time_warp:
              No time warp mode (the default)

           single_time_warp:
              Single time warp mode

           multi_time_warp:
              Multi-time warp mode

         +d:
           If the emulator detects an internal error (or runs out of  memory),
           it,  by  default,  generates both a crash dump and a core dump. The
           core dump is, however, not very useful as the  content  of  process
           heaps is destroyed by the crash dump generation.

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

           Calling erlang:halt/1 with a string argument still produces a crash
           dump. On Unix systems, sending an emulator process a SIGUSR1 signal
           also forces a crash dump.

         +e Number:
           Sets the maximum number of ETS tables.

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

         +fnl:
           The  virtual  machine  works  with filenames as if they are encoded
           using the ISO Latin-1 encoding, disallowing Unicode characters with
           code points > 255.

           For  more  information about Unicode filenames, see section Unicode
           Filenames in the STDLIB User's Guide. Notice that this  value  also
           applies  to  command-line parameters and environment variables (see
           section  Unicode in Enviroment and Parameters in the STDLIB  User's
           Guide).

         +fnu[{w|i|e}]:
           The  virtual  machine  works  with filenames 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,
           that is, Windows and MacOS X.

           The +fnu switch can be followed by  w,  i,  or  e  to  control  how
           wrongly encoded filenames are to be reported:

           * w  means  that  a  warning is sent to the error_logger whenever a
             wrongly encoded filename is "skipped" in directory listings. This
             is the default.

           * i  means  that  those  wrongly  encoded  filenames  are  silently
             ignored.

           * e means that the API function returns an error whenever a wrongly
             encoded filename (or directory name) is encountered.

           Notice  that  file:read_link/1  always returns an error if the link
           points to an invalid filename.

           For more information about Unicode filenames, see  section  Unicode
           Filenames  in  the STDLIB User's Guide. Notice that this value also
           applies to command-line parameters and environment  variables  (see
           section   Unicode in Enviroment and Parameters in the STDLIB User's
           Guide).

         +fna[{w|i|e}]:
           Selection between +fnl and +fnu is done based on the current locale
           settings  in  the OS. This means that if you have set your terminal
           for UTF-8 encoding, the filesystem is  expected  to  use  the  same
           encoding  for  filenames. This is default on all operating systems,
           except MacOS X and Windows.

           The +fna switch can be followed by w, i, or e. This has  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 have no effect.

           For  more  information about Unicode filenames, see section Unicode
           Filenames in the STDLIB User's Guide. Notice that this  value  also
           applies  to  command-line parameters and environment variables (see
           section  Unicode in Enviroment and Parameters in the STDLIB  User's
           Guide).

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

         +hmax Size:
           Sets the default maximum heap size of processes to the  size  Size.
           Defaults  to  0, which means that no maximum heap size is used. For
           more information, see process_flag(max_heap_size, MaxHeapSize).

         +hmaxel true|false:
           Sets whether to send an error logger message or not  for  processes
           reaching the maximum heap size. Defaults to true. For more informa-
           tion, see process_flag(max_heap_size, MaxHeapSize).

         +hmaxk true|false:
           Sets whether to kill processes reaching the maximum  heap  size  or
           not.    Default    to    true.    For    more    information,   see
           process_flag(max_heap_size, MaxHeapSize).

         +hpds Size:
           Sets the initial process dictionary size of processes to  the  size
           Size.

         +hmqd off_heap|on_heap:
           Sets   the  default  value  for  process  flag  message_queue_data.
           Defaults to on_heap. If +hmqd is not passed, on_heap  will  be  the
           default. For more information, see process_flag(message_queue_data,
           MQD).

         +K true | false:
           Enables or disables the kernel poll functionality if  supported  by
           the  emulator.  Defaults  to false (disabled). If the emulator does
           not support kernel poll, and flag +K is passed to the  emulator,  a
           warning is issued at startup.

         +l:
           Enables  autoload  tracing,  displaying  information  while loading
           code.

         +L:
           Prevents loading information about source filenames and  line  num-
           bers.  This saves some memory, but exceptions do not contain infor-
           mation about the filenames and line numbers.

         +MFlag Value:
           Memory  allocator-specific  flags.  For   more   information,   see
           erts_alloc(3).

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

           Two values are supported for Range:

           latin1:
             The default. Only characters in the ISO Latin-1 range can be con-
             sidered  printable. This means that a character with a code point
             > 255 is never considered printable  and  that  lists  containing
             such  characters  are  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
             can give unexpected results if, for example, your font  does  not
             cover all Unicode characters.

           See also io:printable_range/0 in STDLIB.

         +P Number:
           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

         +Q Number:
           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 cho-
           sen 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.

         +R ReleaseNumber:
           Sets the compatibility mode.

           The distribution mechanism is not backward compatible  by  default.
           This  flag  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 emu-
           lator, making it possible for it to communicate with  Erlang  nodes
           (as well as C- and Java nodes) running that earlier release.

     Note:
         Ensure  that all nodes (Erlang-, C-, and Java nodes) of a distributed
         Erlang system is of the same Erlang/OTP release, or from two  differ-
         ent Erlang/OTP releases X and Y, where all Y nodes have compatibility
         mode X.


         +r:
           Forces ETS memory block to be moved on realloc.

         +rg ReaderGroupsLimit:
           Limits the number of reader groups used by read/write  locks  opti-
           mized  for read operations in the Erlang runtime system. By default
           the reader groups limit is 64.

           When the number of schedulers is less than or equal to  the  reader
           groups  limit,  each  scheduler  has its own reader group. When the
           number of schedulers is larger than the reader groups limit, sched-
           ulers  share  reader groups. Shared reader groups degrade read lock
           and read unlock performance while many reader groups degrade  write
           lock  performance.  So, the limit is a tradeoff between performance
           for read operations and  performance  for  write  operations.  Each
           reader group consumes 64 byte in each read/write lock.

           Notice  that  a  runtime system using shared reader groups benefits
           from binding schedulers to logical processors, as 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  maxi-
           mum  for  both values is 1024. If the Erlang runtime system is able
           to determine the number of logical processors configured and  logi-
           cal processors available, Schedulers defaults to logical processors
           configured, and SchedulersOnline  defaults  to  logical  processors
           available;  otherwise  the  default values are 1. Schedulers can be
           omitted if :SchedulerOnline is not and conversely.  The  number  of
           schedulers  online  can  be  changed at runtime through erlang:sys-
           tem_flag(schedulers_online, SchedulersOnline).

           If Schedulers or SchedulersOnline is specified as a  negative  num-
           ber,  the  value  is  subtracted from the default number of logical
           processors configured  or  logical  processors  available,  respec-
           tively.

           Specifying  value  0  for Schedulers or SchedulersOnline resets the
           number of scheduler threads or scheduler  threads  online,  respec-
           tively, to its default value.

           This  option  is  ignored if the emulator does not have SMP support
           enabled (see flag -smp).

         +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 avail-
           able, when SMP support has been enabled. Specified values must be >
           0. For example, +SP 50:25 sets the number of scheduler  threads  to
           50%  of the logical processors configured, and the number of sched-
           uler threads online to 25% of  the  logical  processors  available.
           SchedulersPercentage  can be omitted if :SchedulersOnlinePercentage
           is not and conversely. The  number  of  schedulers  online  can  be
           changed  at  runtime  through 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 does not  have  SMP  support
           enabled (see flag -smp).

         +SDcpu DirtyCPUSchedulers:DirtyCPUSchedulersOnline:
           Sets  the number of dirty CPU scheduler threads to create and dirty
           CPU scheduler threads to set online when threading support has been
           enabled.  The  maximum  for  both values is 1024, and each value is
           further limited by the settings for normal schedulers:

           * The number of dirty CPU scheduler threads created  cannot  exceed
             the number of normal scheduler threads created.

           * The  number  of  dirty CPU scheduler threads online cannot exceed
             the number of normal scheduler threads online.

           For details, see the +S and +SP. By default, the  number  of  dirty
           CPU scheduler threads created equals the number of normal scheduler
           threads created, and the number  of  dirty  CPU  scheduler  threads
           online equals the number of normal scheduler threads online. Dirty-
           CPUSchedulers can be omitted if  :DirtyCPUSchedulersOnline  is  not
           and  conversely.  The  number of dirty CPU schedulers online can be
           changed  at  runtime  through   erlang:system_flag(dirty_cpu_sched-
           ulers_online, DirtyCPUSchedulersOnline).

           The amount of dirty CPU schedulers is limited by the amount of nor-
           mal schedulers in order to limit the effect on processes  executing
           on  ordinary  schedulers. If the amount of dirty CPU schedulers was
           allowed to be unlimited, dirty CPU  bound  jobs  would  potentially
           starve normal jobs.

           This option is ignored if the emulator does not have threading sup-
           port enabled. This option is experimental and is supported only  if
           the emulator was configured and built with support for dirty sched-
           ulers enabled (it is disabled by default).

         +SDPcpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercent-
         age:
           Similar  to  +SDcpu but uses percentages to set the number of dirty
           CPU scheduler threads to create and the number of dirty CPU  sched-
           uler threads to set online when threading support has been enabled.
           Specified values must be > 0. For example, +SDPcpu 50:25  sets  the
           number of dirty CPU scheduler threads to 50% of the logical proces-
           sors configured and the  number  of  dirty  CPU  scheduler  threads
           online  to  25% of the logical processors available. DirtyCPUSched-
           ulersPercentage can be omitted if :DirtyCPUSchedulersOnlinePercent-
           age  is  not  and  conversely.  The  number of dirty CPU schedulers
           online   can   be   changed   at   runtime   through    erlang:sys-
           tem_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).

           This  option interacts with +SDcpu settings. For example, on a sys-
           tem with 8 logical cores configured and 8 logical cores  available,
           the  combination of the options +SDcpu 4:4 +SDPcpu 50:25 (in either
           order) results in 2 dirty CPU scheduler threads (50% of  4)  and  1
           dirty CPU scheduler thread online (25% of 4).

           This option is ignored if the emulator does not have threading sup-
           port enabled. This option is experimental and is supported only  if
           the emulator was configured and built with support for dirty sched-
           ulers enabled (it is disabled by default).

         +SDio DirtyIOSchedulers:
           Sets the number of dirty  I/O  scheduler  threads  to  create  when
           threading  support  has  been  enabled.  Valid  range is 0-1024. By
           default, the number of dirty I/O scheduler threads created  is  10,
           same as the default number of threads in the async thread pool.

           The  amount  of dirty IO schedulers is not limited by the amount of
           normal schedulers like the amount of  dirty  CPU  schedulers.  This
           since  only  I/O  bound  work  is  expected to execute on dirty I/O
           schedulers. If the user should schedule CPU bound jobs on dirty I/O
           schedulers,  these  jobs  might  starve  ordinary jobs executing on
           ordinary schedulers.

           This option is ignored if the emulator does not have threading sup-
           port  enabled. This option is experimental and is supported only if
           the emulator was configured and built with support for dirty sched-
           ulers enabled (it is disabled by default).

         +sFlag Value:
           Scheduling specific flags.

           +sbt BindType:
             Sets scheduler bind type.

             Schedulers  can  also be bound using flag +stbt. The only differ-
             ence between these two flags is how the following errors are han-
             dled:

             * Binding  of  schedulers  is not supported on the specific plat-
               form.

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

             If any of these errors occur when +sbt has been passed, the  run-
             time system prints an error message, and refuses to start. If any
             of these errors occur when +stbt has  been  passed,  the  runtime
             system  silently  ignores  the  error, and start up using unbound
             schedulers.

             Valid BindTypes:

             u:
               unbound - Schedulers are not bound to logical processors,  that
               is,  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  are
               bound as close as possible in hardware.

             ts:
               thread_spread  -  Thread  refers  to  hardware threads (such as
               Intel's hyper-threads). Schedulers with low  scheduler  identi-
               fiers,  are  bound  to  the first hardware thread of each core,
               then schedulers with higher scheduler identifiers are bound  to
               the second hardware thread of each core,and so on.

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

             s:
               spread - Schedulers are spread as much as possible.

             nnts:
               no_node_thread_spread - Like  thread_spread,  but  if  multiple
               Non-Uniform  Memory  Access  (NUMA) nodes exist, schedulers are
               spread over one NUMA node at a time, that is, all logical  pro-
               cessors of one NUMA node are bound to schedulers in sequence.

             nnps:
               no_node_processor_spread - Like processor_spread, but if multi-
               ple NUMA nodes exist, schedulers are spread over one NUMA  node
               at a time, that is, all logical processors of one NUMA node are
               bound to schedulers in sequence.

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

             db:
               default_bind - Binds schedulers the default  way.  Defaults  to
               thread_no_node_processor_spread   (which   can  change  in  the
               future).

             Binding of schedulers is only supported on newer Linux,  Solaris,
             FreeBSD, and Windows systems.

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

             The runtime system does 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 perfor-
           mance of the runtime system. However,  if  other  operating  system
           processes  (for  example  another  Erlang runtime system) also bind
           threads to logical processors, there can be a  performance  penalty
           instead.  This  performance penalty can sometimes be severe. If so,
           you are advised not to 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 are  available  to  the  runtime
             system in such situations.

       Note:
           If a scheduler fails to bind, this is often silently ignored, as it
           is not always possible to verify valid  logical  processor  identi-
           fiers. If an error is reported, it is reported to the error_logger.
           If you want to verify that the schedulers have bound as  requested,
           call erlang:system_info(scheduler_bindings).


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

       Note:
           This  flag  can  be  removed  or  changed at any time without prior
           notice.


           +scl true|false:
             Enables or disables scheduler  compaction  of  load.  By  default
             scheduler  compaction of load is enabled. When enabled, load bal-
             ancing strives for a load  distribution,  which  causes  as  many
             scheduler  threads  as  possible to be fully loaded (that is, not
             run out of work). This is accomplished  by  migrating  load  (for
             example,  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 is not taken into
             account by the load balancing logic.

             +scl false is similar to +sub true, but +sub true  also  balances
             scheduler utilization between schedulers.

           +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><Proces-
               sorIds><NodeIds>         |         <LogicalIds><ThreadIds><Cor-
               eIds><NodeIds><ProcessorIds>

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

             Sets  a  user-defined CPU topology. The user-defined CPU topology
             overrides any automatically detected CPU topology. The CPU topol-
             ogy is used when binding schedulers to logical processors.

             Uppercase  letters signify real identifiers and lowercase letters
             signify fake identifiers only used for description of the  topol-
             ogy.  Identifiers  passed  as real identifiers can be used by the
             runtime system when trying to access specific hardware;  if  they
             are  incorrect the behavior is undefined. Faked logical CPU iden-
             tifiers are not accepted, as there is no point  in  defining  the
             CPU  topology without real logical CPU identifiers. Thread, core,
             processor, and node identifiers can be omitted. If  omitted,  the
             thread ID defaults to t0, the core ID defaults to c0, the proces-
             sor ID defaults to p0, and the node ID is left undefined.  Either
             each  logical  processor must belong to 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  must 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 implies the hierarchy of the
             CPU topology. The valid orders are as follows:

             * <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>,   that
               is, thread is part of a core that is part of a processor, which
               is part of a NUMA node.

             * <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>,   that
               is, thread is part of a core that is part of a NUMA node, which
               is part of a processor.

             A CPU topology can consist of both processor external,  and  pro-
             cessor  internal  NUMA  nodes  as  long as each logical processor
             belongs to only one NUMA node. If <ProcessorIds> is omitted,  its
             default  position  is  before  <NodeIds>. That is, the default is
             processor external NUMA nodes.

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

             * <LogicalIds> must be a list of identifiers.

             * At least one other identifier type  besides  <LogicalIds>  must
               also have a list of identifiers.

             * All  lists of identifiers must produce the same number of iden-
               tifiers.

             A simple example. A single quad core processor can  be  described
             as follows:

           % 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  more  complicated  example with two quad core processors, each
             processor in its own NUMA node. The ordering of  logical  proces-
             sors  is a bit weird. This 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 OK to pass  a  CPU
             topology  that  is not a correct description of the CPU topology.
             When used with care this can be very useful. This  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 number 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.

             Notice  that  a  faked CPU topology that does not reflect how the
             real CPU topology looks like is likely to  decrease  the  perfor-
             mance of the runtime system.

             For more information, see erlang:system_info(cpu_topology).

           +secio true|false:
             Enables or disables eager check I/O scheduling. Defaults to true.
             The default was changed from false as from ERTS 7.0. The behavior
             before this flag was introduced corresponds to +secio false.

             The  flag  effects  when schedulers will check for I/O operations
             possible to execute, and when such I/O operations  will  execute.
             As the parameter name implies, schedulers are more eager to check
             for I/O when true is passed. This,  however,  also  implies  that
             execution  of outstanding I/O operation is not prioritized to the
             same extent as when false is passed.

             erlang:system_info(eager_check_io)  returns  the  value  of  this
             parameter used when starting the virtual machine.

           +sfwi Interval:
             Sets scheduler-forced wakeup interval. All run queues are scanned
             each Interval milliseconds. While there are  sleeping  schedulers
             in  the  system,  one  scheduler  is woken for each non-empty run
             queue found. Interval default to 0, meaning this feature is  dis-
             abled.

       Note:
           This  feature  has  been  introduced  as a temporary workaround for
           long-executing native code, and native  code  that  does  not  bump
           reductions  properly  in  OTP.  When these bugs have be fixed, this
           flag will be removed.


           +spp Bool:
             Sets default scheduler hint for port parallelism. If set to true,
             the  virtual machine schedules port tasks when it improves paral-
             lelism in the system. If set to false, the virtual machine  tries
             to  perform  port  tasks  immediately,  improving  latency at the
             expense of parallelism. Default to false. The default used can be
             inspected in runtime by calling erlang:system_info(port_parallel-
             ism). The default can be overridden on port creation  by  passing
             option parallelism to erlang: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-depen-
             dent.

           +stbt BindType:
             Tries  to  set  the  scheduler  bind  type. The same as flag +sbt
             except how some errors are handled.  For  more  information,  see
             +sbt.

           +sub true|false:
             Enables  or disables  scheduler utilization balancing of load. By
             default scheduler utilization balancing is disabled  and  instead
             scheduler compaction of load is enabled, which strives for a load
             distribution that causes as many scheduler threads as possible to
             be  fully  loaded  (that is, not run out of work). When scheduler
             utilization balancing is enabled, the  system  instead  tries  to
             balance scheduler utilization between schedulers. That is, strive
             for equal scheduler utilization on all schedulers.

             +sub true is only supported on systems where the  runtime  system
             detects  and  uses  a  monotonically  increasing  high-resolution
             clock. On other systems, the runtime system fails to start.

             +sub true implies +scl false. The difference  between  +sub  true
             and  +scl  false  is  that +scl false does not try to balance the
             scheduler utilization.

           +swct very_eager|eager|medium|lazy|very_lazy:
             Sets scheduler wake cleanup threshold. Defaults to  medium.  Con-
             trols how eager schedulers are to be requesting wakeup because of
             certain cleanup operations. When a lazy  setting  is  used,  more
             outstanding  cleanup operations can be left undone while a sched-
             uler is idling. When an eager setting  is  used,  schedulers  are
             more frequently woken, potentially increasing CPU-utilization.

       Note:
           This  flag  can  be  removed  or  changed at any time without prior
           notice.


           +sws default|legacy:
             Sets scheduler wakeup strategy. Default strategy changed in  ERTS
             5.10  (Erlang/OTP  R16A).  This strategy was known as proposal in
             Erlang/OTP R15. The legacy strategy was used as default from  R13
             up to and including R15.

       Note:
           This  flag  can  be  removed  or  changed at any time without prior
           notice.


           +swt very_low|low|medium|high|very_high:
             Sets scheduler wakeup threshold. Defaults to medium. The  thresh-
             old determines when to wake up sleeping schedulers when more work
             than can be handled by currently awake schedulers exists.  A  low
             threshold  causes  earlier  wakeups,  and a high threshold causes
             later wakeups. Early wakeups distribute work over multiple sched-
             ulers  faster,  but  work  does more easily bounce between sched-
             ulers.

       Note:
           This flag can be removed or  changed  at  any  time  without  prior
           notice.


         +t size:
           Sets  the  maximum  number of atoms the virtual machine can handle.
           Defaults to 1,048,576.

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

           Modified timing affects the following:

           Process spawning:
             A  process calling spawn, spawn_link, spawn_monitor, or spawn_opt
             is scheduled out immediately  after  completing  the  call.  When
             higher  modified  timing  levels are used, the caller also sleeps
             for a while after it is scheduled out.

           Context reductions:
             The number of reductions a process is allowed to use before it is
             scheduled out is increased or reduced.

           Input reductions:
             The  number  of  reductions  performed  before  checking  I/O  is
             increased or reduced.

     Note:
         Performance suffers when modified timing is  enabled.  This  flag  is
         only intended for testing and debugging.

         return_to and return_from trace messages are lost when tracing on the
         spawn BIFs.

         This flag can be removed or changed at any time without prior notice.


         +v:
           Verbose.

         +V:
           Makes the emulator print its version number.

         +W w | i | e:
           Sets the mapping of warning  messages  for  error_logger.  Messages
           sent  to  the error logger using one of the warning routines can be
           mapped to errors (+W e), warnings (+W w),  or  information  reports
           (+W  i). Defaults to warnings. The current mapping can be retrieved
           using  error_logger:warning_map/0.  For   more   information,   see
           error_logger:warning_map/0 in Kernel.

         +zFlag Value:
           Miscellaneous flags:

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

             A larger buffer limit allows 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 gives lower latency and  higher  throughput  at  the
             expense of higher memory use.

           +zdntgc time:
             Sets   the   delayed   node   table   garbage   collection   time
             (delayed_node_table_gc)  in  seconds.  Valid  values  are  either
             infinity or an integer in the range 0-100000000. Defaults to 60.

             Node  table entries that are not referred linger in the table for
             at least the amount of time that this parameter  determines.  The
             lingering  prevents  repeated  deletions  and  insertions  in the
             tables from occurring.

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

         ERL_CRASH_DUMP_NICE:
           Unix  systems: If the emulator needs to write a crash dump, it uses
           the value of this variable to set the nice value for  the  process,
           thus  lowering its priority. Valid range is 1-39 (higher values are
           replaced with 39). The highest value, 39,  gives  the  process  the
           lowest priority.

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

           If the variable is not set or set to 0 seconds (ERL_CRASH_DUMP_SEC-
           ONDS=0),  the  runtime  system  does  not even attempt to write the
           crash dump file. It only terminates.

           If   the   variable   is   set   to   negative   value,   such   as
           ERL_CRASH_DUMP_SECONDS=-1,  the  runtime  system waits indefinitely
           for the crash dump file to be written.

           This variable is used with heart(3) 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  causes  the
             termination  of  the  runtime system to wait until the crash dump
             file has been completly written.

           ERL_CRASH_DUMP_SECONDS=S:
             Waits for S seconds to complete the crash dump file and then ter-
             minates the runtime system.

         ERL_CRASH_DUMP_BYTES:
           This  variable sets the maximum size of a crash dump file in bytes.
           The crash dump will be truncated if this limit is exceeded. If  the
           variable  is  not set, no size limit is enforced by default. If the
           variable is set to 0, the runtime system does not even  attempt  to
           write a crash dump file.

           Introduced in ERTS 8.1.2 (Erlang/OTP 19.2).

         ERL_AFLAGS:
           The  content of this variable is added to the beginning of the com-
           mand line for erl.

           Flag -extra is treated in a special way. Its scope ends at the  end
           of  the environment variable content. Arguments following an -extra
           flag are moved on the command line into section  -extra,  that  is,
           the end of the command line following an -extra flag.

         ERL_ZFLAGS and ERL_FLAGS:
           The  content of these variables are added to the end of the command
           line for erl.

           Flag -extra is treated in a special way. Its scope ends at the  end
           of  the environment variable content. Arguments following an -extra
           flag are moved on the command line into section  -extra,  that  is,
           the end of the command line following an -extra flag.

         ERL_LIBS:
           Contains  a  list  of  additional library directories that the code
           server searches for applications and adds to  the  code  path;  see
           code(3).

         ERL_EPMD_ADDRESS:
           Can be set to a comma-separated list of IP addresses, in which case
           the epmd daemon listens 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:
           Can contain the port number to use when  communicating  with  epmd.
           The  default port works 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 num-
           ber.

SIGNALS
       On Unix systems, the Erlang runtime will interpret two  types  of  sig-
       nals.

         SIGUSR1:
           A SIGUSR1 signal forces a crash dump.

         SIGTERM:
           A  SIGTERM will produce a stop message to the init process. This is
           equivalent to a init:stop/0 call.

           Introduced in ERTS 8.3 (Erlang/OTP 19.3)

       The signal SIGUSR2 is reserved for internal usage. No other signals are
       handled.

CONFIGURATION
       The  standard  Erlang/OTP  system  can  be  reconfigured  to change the
       default behavior on startup.

         The .erlang startup 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 that 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, the Erlang/OTP environment can be custom-
           ized. More powerful changes can be made by  supplying  command-line
           arguments  in  the  startup  script  erl. For more information, see
           init(3).

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



Ericsson AB                        erts 8.3                             erl(1)