Go to main content

man pages section 5: File Formats

Exit Print View

Updated: Wednesday, February 9, 2022

script (5erl)


script - Boot script


Please see following description for synopsis


script(5)                            Files                           script(5)

       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.

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

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

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

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

           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 mod-
           ules  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  ter-
           minates  if  this  results in an error. The boot procedure hangs if
           this function never returns.

       In an interactive system, the code loader provides  demand-driven  code
       loading, but in an embedded system the code loader loads all code imme-
       diately. 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.


Ericsson AB                        sasl 4.1                          script(5)