Fix typos in System Principles

Co-authored-by: Maria Scott <maria-12648430@hnc-agency.org>

Author: juhlig

system/doc/system_principles/create_target.md

@@ -45,7 +45,7 @@ functionality:
   script.
 - A _simple target system_ that also supports code replacement in runtime.
 - An _embedded target system_ that also supports starting automatically
-  at boot time, and logging output from the system files for later inspection.
+  at boot time, and logging output from the system to files for later inspection.
 
 Here is only considered the case when Erlang/OTP is running on a UNIX system.
 
@@ -122,7 +122,7 @@ lib/sasl-2.3.4/
 lib/pea-1.0/
 ```
 
-The file `releases/FIRST/start.boot` is a copy of our `mysystem.boot`
+The file `releases/FIRST/start.boot` is a copy of our `mysystem.boot`.
 
 The release resource file `mysystem.rel` is duplicated in the tar file.
 Originally, this file was only stored in the `releases` directory to make it
@@ -204,7 +204,7 @@ script calls `bin/run_erl`, which in turn calls `bin/start_erl` (roughly,
 `start_erl` is an embedded variant of `erl`).
 
 The shell script `start`, which is generated from `erts-5.10.4/bin/start.src`
-during installation, is merely an example. Edit it to suite your needs. Typically
+during installation, is merely an example. Edit it to suit your needs. Typically
 it is executed when the UNIX system boots.
 
 `run_erl` is a wrapper that provides logging of output from the runtime system
@@ -214,7 +214,7 @@ to file. It also provides a simple mechanism for attaching to the Erlang shell
 `start_erl` requires:
 
 1. The root directory (`"/usr/local/erl-target"`)
-1. The releases directory (`"/usr/local/erl-target/releases"`
+1. The releases directory (`"/usr/local/erl-target/releases"`)
 1. The location of the file `start_erl.data`
 
 It performs the following:
@@ -225,7 +225,7 @@ It performs the following:
 1. Provides the flag `-boot` specifying the boot file of the release version
    found (`"releases/FIRST/start.boot"`).
 
-`start_erl` also assumes that there is `sys.config` in the release version
+`start_erl` also assumes that there is a `sys.config` in the release version
 directory (`"releases/FIRST/sys.config"`). That is the topic of the next
 section.
 
@@ -244,7 +244,7 @@ In fact, if you in the current directory create not only the file
 `mysystem.rel`, but also file `sys.config`, the latter file is tacitly put in
 the appropriate directory.
 
-However, it can also be convenient to replace variables in within a `sys.config`
+However, it can also be convenient to replace variables within a `sys.config`
 on the target after unpacking but before running the release. If you have a
 `sys.config.src` it will be included and is not required to be a valid Erlang
 term file like `sys.config`. Before running the release you must have a valid
@@ -256,12 +256,12 @@ booting the release.
 
 The previous `install/2` procedure differs somewhat from that of the ordinary
 `Install` shell script. In fact, `create/1` makes the release package as
-complete as possible, and leave to the `install/2` procedure to finish by only
+complete as possible, and leaves it to the `install/2` procedure to finish by only
 considering location-dependent files.
 
 ## Creating the Next Version
 
-In this example the Pea application has been changed, and so are the
+In this example the Pea application has been changed, and so have the
 applications ERTS, Kernel, STDLIB and SASL.
 
 _Step 1._ Create the file `.rel`:
@@ -371,7 +371,7 @@ It can be accessed as follows:
 ```
 
 Logs can be found in `/usr/local/erl-target/log`. This directory is specified as
-an argument to `run_erl`in the start script listed above.
+an argument to `run_erl` in the start script listed above.
 
 _Step 1._ Unpack the release:
 
@@ -425,7 +425,7 @@ _Step 3._ Make the new release permanent:
 
 Check the releases again:
 
-```c
+```erlang
 3> release_handler:which_releases().
 [{"MYSYSTEM","SECOND",
   ["kernel-3.0","stdlib-2.0","sasl-2.4","pea-2.0"],

system/doc/system_principles/error_logging.md

@@ -62,7 +62,7 @@ compatibility, be enabled by setting the Kernel configuration parameter
 `true`. For more information, see
 [SASL Error Logging](`e:sasl:error_logging.md`) in the SASL User's Guide.
 
-```erlang
+```text
 % erl -kernel logger_level info
 Erlang/OTP 21 [erts-10.0] [source-13c50db] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]
 

system/doc/system_principles/misc.md

@@ -45,7 +45,7 @@ Pull requests are only accepted on the `maint` and the `master`
 branches in our [git repository](https://github.com/erlang/otp). The
 `maint` branch contains changes planned for the next [maintenance
 patch package](versions.md#releases_and_patches) on the latest OTP
-release and the `master` branch contain changes planned for the
+release and the `master` branch contains changes planned for the
 upcoming OTP release.
 
 ## Compatibility
@@ -61,7 +61,7 @@ are handled.
   preceding and two subsequent releases.
 
 - **Compiled BEAM Code, NIF Libraries, and Drivers** - Compiled code
-  can be loaded on at least two subsequent releases. To achive the
+  can be loaded on at least two subsequent releases. To achieve the
   highest possible performance for Erlang code, ensure it is compiled
   using the same release as the one it will be deployed on.
 
@@ -111,7 +111,7 @@ functionality unless an upcoming removal is explicitly stated in the
 deprecation notice.
 
 Deprecated functionality will be documented as deprecated and highlighted
-in a release note as early possible. If appropriate, the compiler will
+in a release note as early as possible. If appropriate, the compiler will
 issue warnings when the deprecated functionality is used.
 
 There is a page in the documentation regarding deprecations:
@@ -133,7 +133,7 @@ functionality in the language itself and core libraries used during operation.
 There are two pages in the documentation regarding removal:
 
 * [Scheduled for Removal](`e:general_info:scheduled_for_removal.md`) - lists
-  all functionality that is schedule for removal in upcoming releases.
+  all functionality that is scheduled for removal in upcoming releases.
 
 * [Removed Functionality](`e:general_info:removed.md`) - lists
   functionality that has been removed.

system/doc/system_principles/system_principles.md

@@ -143,7 +143,7 @@ For more information about `.rel` files, see
 [Release Handling](`e:system:release_handling.md`) and the
 [rel](`e:sasl:rel.md`) page in SASL.
 
-To generate the binary boot script file `Name.boot` the boot script file
+To generate the binary boot script file `Name.boot` from the boot script file
 `Name.script`, use the
 [`systools:script2boot(File)`](https://www.erlang.org/doc/man/systools#script2boot-1)
 function.

system/doc/system_principles/versions.md

@@ -31,7 +31,7 @@ version scheme used is described in detail in
 [Version Scheme](versions.md#version_scheme).
 
 OTP of a specific version is a set of applications of specific versions. The
-application versions identified by an OTP version corresponds to application
+application versions identified by an OTP version correspond to application
 versions that have been tested together by the Erlang/OTP team at Ericsson AB.
 An OTP system can, however, be put together with applications from different OTP
 versions. Such a combination of application versions has not been tested by the
@@ -50,7 +50,7 @@ constructed by calling
 
 In an installed OTP development system, the OTP version can be read from the
 text file `<OTP installation root>/releases/<OTP release number>/OTP_VERSION`.
-The absolute path to the file can by constructed by calling
+The absolute path to the file can be constructed by calling
 `filename:join([`[`code:root_dir()`](`code:root_dir/0`)`, "releases", `[`erlang:system_info(otp_release)`](`m:erlang#system_info_otp_release`)`, "OTP_VERSION"]).`
 
 If the version read from the `OTP_VERSION` file in a development system has a
@@ -82,7 +82,7 @@ that are part of a specific OTP version, and has the following format:
 to identify the source.
 
 `<ChangedAppVersions>` and `<UnchangedAppVersions>` are space-separated lists of
-application versions and has the format `<application>-<vsn>`.
+application versions and have the format `<application>-<vsn>`.
 
 - `<ChangedAppVersions>` corresponds to changed applications with new version
   numbers in this OTP version.
@@ -134,7 +134,7 @@ Normally, a version is constructed as `<Major>.<Minor>.<Patch>`, where
 dot-separated parts are possible.
 
 The dot-separated parts consist of non-negative integers. If all parts
-less significant than `<Minor>` equals `0`, they are omitted. The
+less significant than `<Minor>` equal `0`, they are omitted. The
 three normal parts `<Major>.<Minor>.<Patch>` are changed as follows:
 
 - `<Major>` - Increases when major changes, including incompatibilities, are
@@ -198,9 +198,9 @@ usually contain more changes than emergency patch packages. Emergency patch
 packages are released to solve one or more specific issues when such are
 discovered.
 
-The release of a maintenance patch package usually imply an increase
+The release of a maintenance patch package usually implies an increase
 of the OTP `<Minor>` version, while the release of an emergency patch
-package usually imply an increase of the OTP `<Patch>`
+package usually implies an increase of the OTP `<Patch>`
 version. However, this is not always the case, as changes in OTP
 versions are determined by actual code modifications rather than
 whether the patch was planned or not. For more information see