From 84adefa331c4159d432d22840663c38f155cd4c1 Mon Sep 17 00:00:00 2001 From: Erlang/OTP Date: Fri, 20 Nov 2009 14:54:40 +0000 Subject: The R13B03 release. --- lib/sasl/doc/src/script.xml | 168 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 168 insertions(+) create mode 100644 lib/sasl/doc/src/script.xml (limited to 'lib/sasl/doc/src/script.xml') diff --git a/lib/sasl/doc/src/script.xml b/lib/sasl/doc/src/script.xml new file mode 100644 index 0000000000..6bac07d106 --- /dev/null +++ b/lib/sasl/doc/src/script.xml @@ -0,0 +1,168 @@ + + + + +
+ + 1997 + 2007 + Ericsson AB, All Rights Reserved + + + The contents of this file are subject to the Erlang Public License, + Version 1.1, (the "License"); you may not use this file except in + compliance with the License. You should have received a copy of the + Erlang Public License along with this software. If not, it can be + retrieved online at http://www.erlang.org/. + + Software distributed under the License is distributed on an "AS IS" + basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See + the License for the specific language governing rights and limitations + under the License. + + The Initial Developer of the Original Code is Ericsson AB. + + + script + Martin Björklund + Bjarne Däcker + + Bjarne Däcker + + 97-06-03 + A + script.sgml +
+ 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 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. + + + +

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(3) +

+
+ + -- cgit v1.2.3