File 0649-Fix-typos-in-System-Principles.patch of Package erlang
From 2915438a3e1e478bfc5beb3af167b85dcef689b5 Mon Sep 17 00:00:00 2001
From: Jan Uhlig <juhlig@hnc-agency.org>
Date: Mon, 16 Mar 2026 13:07:40 +0100
Subject: [PATCH] Fix typos in System Principles
Co-authored-by: Maria Scott <maria-12648430@hnc-agency.org>
---
system/doc/system_principles/create_target.md | 20 +++++++++----------
system/doc/system_principles/error_logging.md | 2 +-
system/doc/system_principles/misc.md | 8 ++++----
.../system_principles/system_principles.md | 2 +-
system/doc/system_principles/versions.md | 12 +++++------
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/system/doc/system_principles/create_target.md b/system/doc/system_principles/create_target.md
index c6326d3112..1337b75c0b 100644
--- a/system/doc/system_principles/create_target.md
+++ b/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"],
diff --git a/system/doc/system_principles/error_logging.md b/system/doc/system_principles/error_logging.md
index 9fd66b63bd..e861662a94 100644
--- a/system/doc/system_principles/error_logging.md
+++ b/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]
diff --git a/system/doc/system_principles/misc.md b/system/doc/system_principles/misc.md
index a5f10ec2cd..b42ba33f8a 100644
--- a/system/doc/system_principles/misc.md
+++ b/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.
diff --git a/system/doc/system_principles/system_principles.md b/system/doc/system_principles/system_principles.md
index 4b203aa34e..437dd666a9 100644
--- a/system/doc/system_principles/system_principles.md
+++ b/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.
diff --git a/system/doc/system_principles/versions.md b/system/doc/system_principles/versions.md
index a0e60e1d2f..92adaa6c64 100644
--- a/system/doc/system_principles/versions.md
+++ b/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
--
2.51.0
