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.

       The 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 .app files.

FILE SYNTAX

       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, ...]},
         ...
         {kernel_load_completed},
         {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 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  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.

   Note:
       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.

SEE ALSO

       systools(3erl)