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
              behavior of the emulator.

            * Any   argument   starting   with  character  -  (hyphen)  is
              interpreted 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(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.

              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
          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. 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 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 flag '-args_file FileName'  on
       the resulting command line.

       The  file  FileName  is  to  be  a  plain text file and can contain
       comments and command-line arguments. A  comment  begins  with  a  #
       character  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(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 in SASL.

     -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 does 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 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
       environment variable DISPLAY 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 heartbeat 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 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(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 flag -loader inet is present.

       The  IP  addresses  must  be  specified  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 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
       runtime  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(3erl). 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(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 is to load code dynamically (interactive),
       or if all  code  is  to  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).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(3erl).

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

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

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

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

     -smp [enable|auto|disable]:
       -smp  enable  and  -smp  start  the  Erlang runtime system with SMP
       support 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 processor 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
       delivered  with Erlang/OTP, but might not be large enough for other
       dynamically  linked-in  drivers   that   use   the   driver_async()
       functionality.  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
       invoking 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
       information, 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
       numbers. This saves some memory,  but  exceptions  do  not  contain
       information about the filenames and line numbers.

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

     +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
         considered 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
       chosen  value  will  increased  to  a  value larger or equal to the
       maximum amount of file descriptors that can be opened.

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

     +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
       emulator,  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
     different 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
       optimized 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,
       schedulers 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
       maximum  for  both  values is 1024. If the Erlang runtime system is
       able to determine the number of logical processors  configured  and
       logical   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:system_flag(schedulers_online,
       SchedulersOnline).

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

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

       This option is ignored if the emulator 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
       available, 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
       scheduler   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.
       DirtyCPUSchedulers  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_schedulers_online,
       DirtyCPUSchedulersOnline).

       The  amount  of  dirty  CPU  schedulers is limited by the amount of
       normal 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
       support enabled. This option is experimental and is supported  only
       if  the  emulator  was  configured and built with support for dirty
       schedulers enabled (it is disabled by default).

     +SDPcpu
     DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercentage:
       Similar  to  +SDcpu but uses percentages to set the number of dirty
       CPU scheduler threads  to  create  and  the  number  of  dirty  CPU
       scheduler  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 processors configured and the number of dirty CPU scheduler
       threads   online  to  25%  of  the  logical  processors  available.
       DirtyCPUSchedulersPercentage      can      be      omitted       if
       :DirtyCPUSchedulersOnlinePercentage  is  not  and  conversely.  The
       number of dirty CPU schedulers online can  be  changed  at  runtime
       through             erlang:system_flag(dirty_cpu_schedulers_online,
       DirtyCPUSchedulersOnline).

       This option interacts with  +SDcpu  settings.  For  example,  on  a
       system  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
       support  enabled. This option is experimental and is supported only
       if the emulator was configured and built  with  support  for  dirty
       schedulers 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
       support enabled. This option is experimental and is supported  only
       if  the  emulator  was  configured and built with support for dirty
       schedulers 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
         difference  between  these  two flags is how the following errors
         are handled:

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

         * No  available CPU topology. That is, the runtime system was not
           able to 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
         runtime 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
           identifiers, 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
           processors  of  one  NUMA  node  are  bound  to  schedulers  in
           sequence.

         nnps:
           no_node_processor_spread   -   Like  processor_spread,  but  if
           multiple 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
       performance 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
       identifiers.  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
         balancing 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><ProcessorIds><NodeIds>       |
           <LogicalIds><ThreadIds><CoreIds><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
         topology 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
         topology.  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
         identifiers 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
         processor 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
         processor  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
           identifiers.

         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
         processors  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
         performance 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
         disabled.

   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
         parallelism 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_parallelism).   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-
         dependent.

       +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.
         Controls 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
         scheduler  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
         threshold  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 schedulers faster, but work does more easily bounce
         between schedulers.

   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_SECONDS=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(3erl) 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
         terminates the runtime system.

     ERL_AFLAGS:
       The  content  of  this  variable  is  added to the beginning 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_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(3erl).

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

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
       customized. More powerful changes can be made by supplying command-
       line arguments in the startup script erl. For more information, see
       init(3erl).

SEE ALSO

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





Opportunity


Personal Opportunity - Free software gives you access to billions of dollars of software at no cost. Use this software for your business, personal use or to develop a profitable skill. Access to source code provides access to a level of capabilities/information that companies protect though copyrights. Open source is a core component of the Internet and it is available to you. Leverage the billions of dollars in resources and capabilities to build a career, establish a business or change the world. The potential is endless for those who understand the opportunity.

Business Opportunity - Goldman Sachs, IBM and countless large corporations are leveraging open source to reduce costs, develop products and increase their bottom lines. Learn what these companies know about open source and how open source can give you the advantage.





Free Software


Free Software provides computer programs and capabilities at no cost but more importantly, it provides the freedom to run, edit, contribute to, and share the software. The importance of free software is a matter of access, not price. Software at no cost is a benefit but ownership rights to the software and source code is far more significant.


Free Office Software - The Libre Office suite provides top desktop productivity tools for free. This includes, a word processor, spreadsheet, presentation engine, drawing and flowcharting, database and math applications. Libre Office is available for Linux or Windows.





Free Books


The Free Books Library is a collection of thousands of the most popular public domain books in an online readable format. The collection includes great classical literature and more recent works where the U.S. copyright has expired. These books are yours to read and use without restrictions.


Source Code - Want to change a program or know how it works? Open Source provides the source code for its programs so that anyone can use, modify or learn how to write those programs themselves. Visit the GNU source code repositories to download the source.





Education


Study at Harvard, Stanford or MIT - Open edX provides free online courses from Harvard, MIT, Columbia, UC Berkeley and other top Universities. Hundreds of courses for almost all major subjects and course levels. Open edx also offers some paid courses and selected certifications.


Linux Manual Pages - A man or manual page is a form of software documentation found on Linux/Unix operating systems. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.