NAME

       script - Boot script

DESCRIPTION

       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.

       Command erl -boot Name starts the system with a  boot  file  called  Name.boot,  which  is
       generated from the Name.script file, using systools:script2boot/1.

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

FILE SYNTAX

       The  boot  script  is  stored in a file with extension .script. The file has the following
       syntax:

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

         Name = string():
           Defines the system name.

         Vsn = string():
           Defines the system version.

         {progress, Term}:
           Sets the "progress" of the  initialization  program.  The  init:get_status/0  function
           returns the current value of the progress, which is {InternalStatus,Term}.

         {path, [Dir]}:
           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 that were supplied in the command-line
           arguments. The command-line arguments modify the path as follows:

           * -pa Dir1 Dir2 ... DirN adds the directories DirN, DirN-1, ...,  Dir2,  Dir1  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
             replace  the  search  path given in the script file. Directory names in the path are
             interpreted as follows:

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

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

             * 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 erl_prim_loader:get_file(Mod). A fatal error
           that terminates the system occurs if the module cannot be located.

         {kernel_load_completed}:
           Indicates that all modules that 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  the  "kernel  process"  Name  by  evaluating apply(Mod, Func, Args). The start
           function is to return {ok, Pid} or ignore. The init process monitors the  behavior  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 evaluates apply(Mod, Func,  Args).  The  system  terminates  if  this
           results in an error. The boot procedure hangs if this function never returns.

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

SEE ALSO

       systools(3erl)