aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/doc/src/script.xml
diff options
context:
space:
mode:
authorxsipewe <[email protected]>2015-10-02 13:01:27 +0200
committerSiri Hansen <[email protected]>2015-12-10 13:00:57 +0100
commitf84858101803153a04caeb1b300b80e376fc105d (patch)
tree67cfce8433c76d2fca0c9e771e6088ffc1cb5968 /lib/sasl/doc/src/script.xml
parent4598a8e0b8a318e0541f607897fb6cda1739bdaf (diff)
downloadotp-f84858101803153a04caeb1b300b80e376fc105d.tar.gz
otp-f84858101803153a04caeb1b300b80e376fc105d.tar.bz2
otp-f84858101803153a04caeb1b300b80e376fc105d.zip
sasl: Editorial changes
Diffstat (limited to 'lib/sasl/doc/src/script.xml')
-rw-r--r--lib/sasl/doc/src/script.xml157
1 files changed, 75 insertions, 82 deletions
diff --git a/lib/sasl/doc/src/script.xml b/lib/sasl/doc/src/script.xml
index 838efe69bb..db3ea0f487 100644
--- a/lib/sasl/doc/src/script.xml
+++ b/lib/sasl/doc/src/script.xml
@@ -37,25 +37,21 @@
<file>script</file>
<filesummary>Boot script</filesummary>
<description>
- <p>The <em>boot script</em> describes how the Erlang runtime system is
- started. It contains instructions on which code to load and
- which processes and applications to start.
- </p>
- <p>The command <c>erl -boot Name</c> starts the system with a boot
+ <p>The <em>boot script</em> describes how the Erlang runtime system
+ is started. It contains instructions on which code to load and
+ which processes and applications to start.</p>
+ <p>Command <c>erl -boot Name</c> starts the system with a boot
file called <c>Name.boot</c>, which is generated from the
- <c>Name.script</c> file, using <c>systools:script2boot/1</c>.
- </p>
+ <c>Name.script</c> file, using
+ <seealso marker="systools#script2boot/1"><c>systools:script2boot/1</c></seealso>.</p>
<p>The <c>.script</c> file is generated by <c>systools</c> from a
- <c>.rel</c> file and <c>.app</c> files.
- </p>
+ <c>.rel</c> file and from <c>.app</c> files.</p>
</description>
<section>
- <title>FILE SYNTAX</title>
- <p>The boot script is stored in a file with the extension
- <c>.script</c></p>
- <p>The file has the following syntax:
- </p>
+ <title>File Syntax</title>
+ <p>The boot script is stored in a file with extension
+ <c>.script</c>. The file has the following syntax:</p>
<code type="none">
{script, {Name, Vsn},
[
@@ -70,100 +66,97 @@
...
{apply, {Mod, Func, Args}},
...
- {progress, started}]}. </code>
- <list type="bulleted">
- <item><c>Name = string()</c> defines the name of the system.
- </item>
- <item><c>Vsn = string()</c> defines the version of the system.
- </item>
- <item><c>{progress, Term}</c> sets the "progress" of the
- initialization program. The function <c>init:get_status()</c>
- returns the current value of the progress, which is
- <c>{InternalStatus,Term}</c>.
- </item>
- <item>
- <p><c>{path, [Dir]}</c> where <c>Dir</c> is a string. This
+ {progress, started}]}.</code>
+ <taglist>
+ <tag><c>Name = string()</c></tag>
+ <item><p>Defines the system name.</p></item>
+ <tag><c>Vsn = string()</c></tag>
+ <item><p>Defines the system version.</p></item>
+ <tag><c>{progress, Term}</c></tag>
+ <item><p>Sets the "progress" of the initialization
+ program. The
+ <seealso marker="erts:init#get_status/0"><c>init:get_status/0</c></seealso>
+ function returns the current value of the progress, which is
+ <c>{InternalStatus,Term}</c>.</p></item>
+ <tag><c>{path, [Dir]}</c></tag>
+ <item><p><c>Dir</c> is a string. This
argument sets the load path of the system to <c>[Dir]</c>. 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
+ any path flags that were supplied in the command-line
+ arguments. The command-line arguments modify the path as
follows:</p>
<list type="bulleted">
<item><c>-pa Dir1 Dir2 ... DirN</c> adds the directories
<c>Dir1, Dir2, ..., DirN</c> to the front of the initial
- load path.
- </item>
+ load path.</item>
<item><c>-pz Dir1 Dir2 ... DirN</c> adds the directories
<c>Dir1, Dir2, ..., DirN</c> to the end of the initial
- load path.
- </item>
+ load path.</item>
<item>
<p><c>-path Dir1 Dir2 ... DirN</c> defines a set of
- directories <c>Dir1, Dir2, ..., DirN</c> which replaces
+ directories <c>Dir1, Dir2, ..., DirN</c>, which replace
the search path given in the script file. Directory names
in the path are interpreted as follows:</p>
<list type="bulleted">
<item>Directory names starting with <c>/</c> are assumed
- to be absolute path names.
- </item>
+ to be absolute path names.</item>
<item>Directory names not starting with <c>/</c> are
- assumed to be relative the current working directory.
- </item>
+ assumed to be relative the current working directory.</item>
<item>The special <c>$ROOT</c> variable can only be used
- in the script, not as a command line argument. The
+ in the script, not as a command-line argument. The
given directory is relative the Erlang installation
- directory.
- </item>
+ directory.</item>
</list>
</item>
</list>
- </item>
- <item><c>{primLoad, [Mod]}</c> loads the modules <c>[Mod]</c>
- from the directories specified in <c>Path</c>. The script
- interpreter fetches the appropriate module by calling the
- function <c>erl_prim_loader:get_file(Mod)</c>. A fatal error
- which terminates the system will occur if the module cannot be
- located.
- </item>
- <item><c>{kernel_load_completed}</c> indicates that all modules
- which <em>must</em> be loaded <em>before</em> any processes
- are started are loaded. In interactive mode, all
- <c>{primLoad,[Mod]}</c> commands interpreted after this
- command are ignored, and these modules are loaded on demand.
- In embedded mode, <c>kernel_load_completed</c> is ignored, and
- all modules are loaded during system start.
- </item>
- <item><c>{kernelProcess, Name, {Mod, Func, Args}}</c> starts a
- "kernel process". The kernel process <c>Name</c> is started
- by evaluating <c>apply(Mod, Func, Args)</c> which is expected
- to return <c>{ok, Pid}</c> or <c>ignore</c>. The <c>init</c>
- process monitors the behaviour of <c>Pid</c> and terminates
- the system if <c>Pid</c> dies. Kernel processes are key
- components of the runtime system. Users do not normally add
- new kernel processes.
- </item>
- <item><c>{apply, {Mod, Func, Args}}</c>. The init process simply
- evaluates <c>apply(Mod, Func, Args)</c>. The system
- terminates if this results in an error. The boot procedure
- hangs if this function never returns.
- </item>
- </list>
+ </item>
+ <tag><c>{primLoad, [Mod]}</c></tag>
+ <item><p>Loads the modules <c>[Mod]</c>
+ from the directories specified in <c>Path</c>. The script
+ interpreter fetches the appropriate module by calling
+ <seealso marker="erts:erl_prim_loader#get_file/1">
+ <c>erl_prim_loader:get_file(Mod)</c></seealso>. A fatal error
+ that terminates the system occurs if the module cannot be
+ located.</p></item>
+ <tag><c>{kernel_load_completed}</c></tag>
+ <item><p>Indicates that all modules
+ that <em>must</em> be loaded <em>before</em> any processes
+ are started are loaded. In interactive mode, all
+ <c>{primLoad,[Mod]}</c> commands interpreted after this
+ command are ignored, and these modules are loaded on demand.
+ In embedded mode, <c>kernel_load_completed</c> is ignored, and
+ all modules are loaded during system start.</p></item>
+ <tag><c>{kernelProcess, Name, {Mod, Func, Args}}</c></tag>
+ <item><p>Starts the
+ "kernel process" <c>Name</c>
+ by evaluating <c>apply(Mod, Func, Args)</c>. The start function is
+ to return <c>{ok, Pid}</c> or <c>ignore</c>. The <c>init</c>
+ process monitors the behavior of <c>Pid</c> and terminates
+ the system if <c>Pid</c> dies. Kernel processes are key
+ components of the runtime system. Users do not normally add
+ new kernel processes.</p></item>
+ <tag><c>{apply, {Mod, Func, Args}}</c>.</tag>
+ <item><p>The init process
+ evaluates <c>apply(Mod, Func, Args)</c>. The system
+ terminates if this results in an error. The boot procedure
+ hangs if this function never returns.</p></item>
+ </taglist>
<note>
- <p>In the <c>interactive</c> system the code loader provides
- demand driven code loading, but in the <c>embedded</c> system
- the code loader loads all the code immediately. The same
- version of <c>code</c> is used in both cases. The code server
- calls <c>init:get_argument(mode)</c> to find out if it should
- run in demand mode, or non-demand driven mode.
- </p>
+ <p>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 <seealso marker="kernel:code"><c>code</c></seealso>
+ is used in both cases. The code server calls
+ <seealso marker="erts:init#get_argument/1"><c>init:get_argument(mode)</c></seealso>
+ to determine if it is to run in demand mode or non-demand
+ driven mode.</p>
</note>
</section>
<section>
- <title>SEE ALSO</title>
- <p>systools(3)
- </p>
+ <title>See Also</title>
+ <p><seealso marker="systools"><c>systools(3)</c></seealso></p>
</section>
</fileref>