Provided by: erlang-manpages_13.b.3-dfsg-2ubuntu3_all bug


       script - Boot script


       The  boot script describes how the Erlang runtime system is started. It
       contains instructions on which code to load  and  which  processes  and
       applications to start.

       The  command  erl  -boot Name starts the system with a boot file called
       Name.boot,  which  is  generated  from  the  Name.script  file,   using

       The  .script  file  is  generated by systools from a .rel file and .app


       The boot script is stored in a file with the extension .script

       The file has the following syntax:

       {script, {Name, Vsn},
         {progress, loading},
         {preLoaded, [Mod1, Mod2, ...]},
         {path, [Dir1,"$ROOT/Dir",...]}.
         {primLoad, [Mod1, Mod2, ...]},
         {progress, loaded},
         {kernelProcess, Name, {Mod, Func, Args}},
         {apply, {Mod, Func, Args}},
         {progress, started}]}.

         * Name = string() defines the name of the system.

         * Vsn = string() defines the version of the system.

         * {progress, Term} sets the "progress" of the initialization program.
           The  function  init:get_status()  returns  the current value of the
           progress, which is {InternalStatus,Term}.

         * {path, [Dir]} where Dir is a string. This argument  sets  the  load
           path  of the system to [Dir]. The load path used to load modules is
           obtained from the initial load path, which is given in  the  script
           file,  together  with  any  path  flags  which were supplied in the
           command line arguments. The command line arguments modify the  path
           as  follows:  .br .br .RS 2 .TP 2 * -pa Dir1 Dir2 ... DirN adds the
           directories Dir1, Dir2, ..., DirN to the front of the initial  load
           path.  .br  .br .TP 2 * -pz Dir1 Dir2 ... DirN adds the directories
           Dir1, Dir2, ..., DirN to the end of the initial load path. .br  .br
           .TP 2 * -path Dir1 Dir2 ... DirN defines a set of directories Dir1,
           Dir2, ..., DirN which replaces the search path given in the  script
           file.  Directory  names in the path are interpreted as follows: .br
           .br .RS 2 .TP 2 * Directory names starting with / are assumed to be
           absolute  path  names. .br .br .TP 2 * Directory names not starting
           with / are assumed to be relative the  current  working  directory.
           .br  .br .TP 2 * The special $ROOT variable can only be used in the
           script, not as a command line  argument.  The  given  directory  is
           relative the Erlang installation directory. .br .br .RE .br .br .RE

         * {primLoad,  [Mod]}  loads  the  modules  [Mod] from the directories
           specified in Path. The script interpreter fetches  the  appropriate
           module  by  calling  the  function erl_prim_loader:get_file(Mod). A
           fatal error which terminates the system will occur  if  the  module
           cannot be located.

         * {kernel_load_completed}  indicates  that  all modules which must be
           loaded before any processes are started are loaded. In  interactive
           mode,  all {primLoad,[Mod]} commands interpreted after this command
           are ignored, and these modules are loaded on  demand.  In  embedded
           mode,  kernel_load_completed is ignored, and all modules are loaded
           during system start.

         * {kernelProcess, Name, {Mod, Func, Args}} starts a "kernel process".
           The  kernel  process Name is started by evaluating apply(Mod, Func,
           Args) which is expected to return {ok, Pid}  or  ignore.  The  init
           process  monitors the behaviour of Pid and terminates the system if
           Pid dies. Kernel  processes  are  key  components  of  the  runtime
           system. Users do not normally add new kernel processes.

         * {apply,  {Mod,  Func,  Args}}.  The  init  process simply evaluates
           apply(Mod, Func, Args). The system terminates if this results in an
           error. The boot procedure hangs if this function never returns.

           In  the  interactive  system the code loader provides demand driven
           code loading, but in the embedded system the code loader loads  all
           the  code  immediately.  The  same  version of code is used in both
           cases. The code server calls init:get_argument(mode) to find out if
           it should run in demand mode, or non-demand driven mode.