Provided by: erlang-manpages_12.b.3-1_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:

             - -pa  Dir1  Dir2  ... DirN adds the directories Dir1, Dir2, ...,
               DirN to the front of the initial load path.

             - -pz Dir1 Dir2 ... DirN adds the directories  Dir1,  Dir2,  ...,
               DirN to the end of the initial load path.

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

                 o Directory names starting with / are assumed to be  absolute
                   path names.

                 o Directory  names  not  starting  with  /  are assumed to be
                   relative the current working directory.

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

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