sasl: Editorial changes

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>