trusty (5) script.5.gz

Provided by: erlang-manpages_16.b.3-dfsg-1ubuntu2.2_all bug

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)