tree-wide: "human readable" → "human-readable"

Apparently, the spelling with a hyphen is better style in the English
language.

Suggested by: #36165

NEWS

@@ -871,7 +871,7 @@ CHANGES WITH 258 in spe:
         * userdbctl gained a new switch --from-file=. If used the tool will not
           look up a user or group record from the system's user database but
           instead read it from the specified JSON file, and then present it in
-          the usual, human readable fashion.
+          the usual, human-readable fashion.
 
         * systemd-homed gained D-Bus API calls for listing, adding, removing and
           showing use record signing keys.
@@ -8016,7 +8016,7 @@ CHANGES WITH 248:
 
         * systemd-hostnamed now exports the "HardwareVendor" and
           "HardwareModel" D-Bus properties, which are supposed to contain a
-          pair of cleaned up, human readable strings describing the system's
+          pair of cleaned up, human-readable strings describing the system's
           vendor and model. It's typically sourced from the firmware's DMI
           tables, but may be augmented from a new hwdb database. hostnamectl
           shows this in the status output.
@@ -15502,7 +15502,7 @@ CHANGES WITH 220:
           journal-nocow.conf tmpfiles file.
 
         * systemd-journald will now translate audit message types to
-          human readable identifiers when writing them to the
+          human-readable identifiers when writing them to the
           journal. This should improve readability of audit messages.
 
         * The LUKS logic gained support for the offset= and skip=

docs/CATALOG.md

@@ -51,7 +51,7 @@ The text format of the .catalog files is as follows:
 
 * Simple, UTF-8 text files, with usual line breaks at 76 chars.
   URLs and suchlike where line-breaks are undesirable may use longer lines.
-  As catalog files need to be usable on text consoles it is essential that the 76 char line break rule is otherwise followed for human readable text.
+  As catalog files need to be usable on text consoles it is essential that the 76 char line break rule is otherwise followed for human-readable text.
 * Lines starting with `#` are ignored, and may be used for comments.
 
 * The files consist of a series of entries.
@@ -63,7 +63,7 @@ The text format of the .catalog files is as follows:
     Some header fields may appear more than once per entry.
     The following header fields are currently known (but additional fields may be added later):
 
-        * Subject: A short, one-line human readable description of the message
+        * Subject: A short, one-line human-readable description of the message
         * Defined-By: Who defined this message.
 
         Usually a package name or suchlike
@@ -71,7 +71,7 @@ The text format of the .catalog files is as follows:
         This can be a web URL or a telephone number in the tel:// namespace
         * Documentation: URIs for further user, administrator or developer documentation on the log entry. URIs should be listed in order of relevance, the most relevant documentation first.
     * An empty line
-    * The actual catalog entry payload, as human readable prose.
+    * The actual catalog entry payload, as human-readable prose.
       Multiple paragraphs may be separated by empty lines.
       The prose should first describe the message and when it occurs, possibly followed by recommendations how to deal with the message and (if it is an error message) correct the problem at hand.
       This message text should be readable by users and administrators.

docs/PORTABILITY_AND_STABILITY.md

@@ -18,7 +18,7 @@ The stable interfaces are:
 * **The command line interface** of `systemd`, `systemctl`, `loginctl`, `journalctl`, and all other command line utilities installed in `$PATH` and documented in a man page.
   We will make sure that scripts invoking these commands will continue to work with future versions of systemd.
   Note however that the output generated by these commands is generally not included in the promise, unless it is documented in the man page.
-  Example: the output of `systemctl status` is not stable, but that of `systemctl show` is, because the former is intended to be human readable and the latter computer readable, and this is documented in the man page.
+  Example: the output of `systemctl status` is not stable, but that of `systemctl show` is, because the former is intended to be human-readable and the latter computer readable, and this is documented in the man page.
 
 * **The protocol spoken on the socket referred to by `$NOTIFY_SOCKET`**, as documented in
   [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/sd_notify.html). Note that, although using

man/coredumpctl.xml

@@ -52,7 +52,7 @@
         matching specified characteristics. If no command is
         specified, this is the implied default.</para>
 
-        <para>The output is designed to be human readable and contains a table with the following
+        <para>The output is designed to be human-readable and contains a table with the following
         columns:</para>
         <variablelist>
           <varlistentry>

man/homectl.xml

@@ -138,7 +138,7 @@
         <literal>short</literal> or <literal>off</literal>. If <literal>pretty</literal> human-friendly
         whitespace and newlines are inserted in the output to make the JSON data more readable. If
         <literal>short</literal> all superfluous whitespace is suppressed. If <literal>off</literal> (the
-        default) the user information is not shown in JSON format but in a friendly human readable formatting
+        default) the user information is not shown in JSON format but in a friendly human-readable formatting
         instead. The <option>-j</option> option picks <literal>pretty</literal> when run interactively and
         <literal>short</literal> otherwise.</para>
 

man/org.freedesktop.login1.xml

@@ -743,8 +743,8 @@ node /org/freedesktop/login1 {
       <literal>handle-suspend-key</literal>, <literal>handle-hibernate-key</literal>,
       <literal>handle-lid-switch</literal>, separated by colons, for inhibiting poweroff/reboot,
       suspend/hibernate, the automatic idle logic, or hardware key handling. <varname>who</varname> should be
-      a short human readable string identifying the application taking the lock. <varname>why</varname>
+      a short human-readable string identifying the application taking the lock. <varname>why</varname>
-      should be a short human readable string identifying the reason why the lock is taken. Finally,
+      should be a short human-readable string identifying the reason why the lock is taken. Finally,
       <varname>mode</varname> is either <literal>block</literal> or <literal>delay</literal> which encodes
       whether the inhibit shall be consider mandatory or whether it should just delay the operation to a
       certain maximum time, while the <literal>block-weak</literal> and variants will create an inhibitor

man/org.freedesktop.systemd1.xml

@@ -1370,7 +1370,7 @@ node /org/freedesktop/systemd1 {
       <itemizedlist>
         <listitem><para>The primary unit name as string</para></listitem>
 
-        <listitem><para>The human readable description string</para></listitem>
+        <listitem><para>The human-readable description string</para></listitem>
 
         <listitem><para>The load state (i.e. whether the unit file has been loaded
         successfully)</para></listitem>
@@ -2518,7 +2518,7 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
       the dependencies and their inverse dependencies (where this applies) as configured in the unit file or
       determined automatically.</para>
 
-      <para><varname>Description</varname> contains the human readable description string for the
+      <para><varname>Description</varname> contains the human-readable description string for the
       unit.</para>
 
       <para><varname>SourcePath</varname> contains the path to a configuration file this unit is
@@ -2638,7 +2638,7 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
 
       <para><varname>LoadError</varname> contains a pair of strings. If the unit failed to load (as encoded
       in <varname>LoadState</varname>, see above), then this will include a D-Bus error pair consisting of
-      the error ID and an explanatory human readable string of what happened. If it loaded successfully, this
+      the error ID and an explanatory human-readable string of what happened. If it loaded successfully, this
       will be a pair of empty strings.</para>
 
       <para><varname>Transient</varname> contains a boolean that indicates whether the unit was created as a

man/os-release.xml

@@ -455,7 +455,7 @@
           produces the OS. This field is optional.</para>
 
           <para>This name is intended to be exposed in "About this system" UIs or software update UIs when
-          needed to distinguish the OS vendor from the OS itself. It is intended to be human readable.</para>
+          needed to distinguish the OS vendor from the OS itself. It is intended to be human-readable.</para>
 
           <para>Examples: <literal>VENDOR_NAME="Fedora Project"</literal> for Fedora Linux,
           <literal>VENDOR_NAME="Canonical"</literal> for Ubuntu.</para>

man/sd_bus_message_new_method_error.xml

@@ -76,7 +76,7 @@
     example an error name such as
     <literal>org.freedesktop.DBus.Error.NotSupported</literal> or the equivalent
     symbolic <constant>SD_BUS_ERROR_NOT_SUPPORTED</constant>), and the
-    <parameter>message</parameter> field is set as the human readable error message
+    <parameter>message</parameter> field is set as the human-readable error message
     string if present. The error <parameter>e</parameter> must have the
     <parameter>name</parameter> field set, see
     <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>.

man/systemd-notify.xml

@@ -161,7 +161,7 @@
       <varlistentry>
         <term><option>--status=</option></term>
 
-        <listitem><para>Send a free-form human readable status string for the daemon to the service
+        <listitem><para>Send a free-form human-readable status string for the daemon to the service
         manager. This option takes the status string as argument. This is equivalent to
         <command>systemd-notify STATUS=…</command>. For details about the semantics of this option see
         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. This

man/systemd-stub.xml

@@ -374,7 +374,7 @@
     similar format as <literal>.osrel</literal> (i.e. an environment-variable-assignment-block-like list of
     newline separated strings). Currently two fields are defined: <literal>ID=</literal> is supposed to carry
     a short identifying string that identifies the profile
-    (e.g. <literal>ID=factory-reset</literal>). <literal>TITLE=</literal> should contain a human readable
+    (e.g. <literal>ID=factory-reset</literal>). <literal>TITLE=</literal> should contain a human-readable
     string that may appear in the boot menu entry for this profile (e.g. <literal>TITLE='Factory Reset this
     Device'</literal>).</para>
   </refsect1>

man/systemd.unit.xml

@@ -597,7 +597,7 @@
     <variablelist class='unit-directives'>
       <varlistentry>
         <term><varname>Description=</varname></term>
-        <listitem><para>A short human readable title of the unit. This may be used by
+        <listitem><para>A short human-readable title of the unit. This may be used by
         <command>systemd</command> (and other UIs) as a user-visible label for the unit, so this string
         should identify the unit rather than describe it, despite the name. This string also should not just
         repeat the unit name. <literal>Apache2 Web Server</literal> is a good example. Bad examples are

man/sysupdate.features.xml

@@ -71,7 +71,7 @@
       <varlistentry>
         <term><varname>Description=</varname></term>
 
-        <listitem><para>A short human readable description of this feature.
+        <listitem><para>A short human-readable description of this feature.
         This may be used as a label for this feature, so the string should meaningfully identify the feature
         among the features available in <filename>sysupdate.d/</filename>.</para>
 

man/userdbctl.xml

@@ -61,7 +61,7 @@
         <literal>friendly</literal>, <literal>table</literal> or <literal>json</literal>. If
         <literal>classic</literal>, an output very close to the format of <filename>/etc/passwd</filename> or
         <filename>/etc/group</filename> is generated. If <literal>friendly</literal>, a more comprehensive and
-        user friendly, human readable output is generated. If <literal>table</literal>, a minimal, tabular
+        user friendly, human-readable output is generated. If <literal>table</literal>, a minimal, tabular
         output is generated. If <literal>json</literal>, a JSON formatted output is generated. Defaults to
         <literal>friendly</literal> if a user/group is specified on the command line,
         <literal>table</literal> otherwise.</para>

src/boot/boot.c

@@ -100,9 +100,9 @@ typedef struct BootEntry {
         char16_t *id;         /* The unique identifier for this entry (typically the filename of the file defining the entry, possibly suffixed with a profile id) */
         char16_t *id_without_profile; /* same, but without any profile id suffixed */
         char16_t *title_show; /* The string to actually display (this is made unique before showing) */
-        char16_t *title;      /* The raw (human readable) title string of the entry (not necessarily unique) */
+        char16_t *title;      /* The raw (human-readable) title string of the entry (not necessarily unique) */
         char16_t *sort_key;   /* The string to use as primary sort key, usually ID= from os-release, possibly suffixed */
-        char16_t *version;    /* The raw (human readable) version string of the entry */
+        char16_t *version;    /* The raw (human-readable) version string of the entry */
         char16_t *machine_id;
         EFI_HANDLE *device;
         LoaderType type;

src/core/unit.c

@@ -2393,7 +2393,7 @@ static int unit_log_resources(Unit *u) {
                 return log_oom();
 
         /* Invoked whenever a unit enters failed or dead state. Logs information about consumed resources if resource
-         * accounting was enabled for a unit. It does this in two ways: a friendly human readable string with reduced
+         * accounting was enabled for a unit. It does this in two ways: a friendly human-readable string with reduced
          * information and the complete data in structured fields. */
 
         (void) unit_get_cpu_usage(u, &cpu_nsec);

src/fundamental/bootspec-fundamental.c

@@ -17,8 +17,8 @@ bool bootspec_pick_name_version_sort_key(
 
         const sd_char *good_name, *good_version, *good_sort_key;
 
-        /* Find the best human readable title, version string and sort key for a boot entry (using the
+        /* Find the best human-readable title, version string and sort key for a boot entry (using the
-         * os-release(5) fields). Precise is preferred over vague, and human readable over machine
+         * os-release(5) fields). Precise is preferred over vague, and human-readable over machine
          * readable. Thus:
          *
          * 1. First priority gets the PRETTY_NAME field, which is the primary string intended for display,
@@ -28,7 +28,7 @@ bool bootspec_pick_name_version_sort_key(
          * 2. Otherwise we go for IMAGE_ID and IMAGE_VERSION (thus we show details about the image,
          *    i.e. specific combination of packages and configuration), if that concept applies.
          *
-         * 3. Otherwise we go for NAME and VERSION (i.e. human readable OS name and version)
+         * 3. Otherwise we go for NAME and VERSION (i.e. human-readable OS name and version)
          *
          * 4. Otherwise we go for ID and VERSION_ID (i.e. machine readable OS name and version)
          *

src/shared/ask-password-api.h

@@ -19,7 +19,7 @@ typedef enum AskPasswordFlags {
 
 /* Encapsulates the mostly static fields of a password query */
 typedef struct AskPasswordRequest {
-        const char *message;         /* The human readable password prompt when asking interactively */
+        const char *message;         /* The human-readable password prompt when asking interactively */
         const char *keyring;         /* kernel keyring key name (key of "user" type) */
         const char *icon;            /* freedesktop icon spec name */
         const char *id;              /* some identifier used for this prompt for the "ask-password" protocol */

src/systemctl/systemctl.c

@@ -271,7 +271,7 @@ static int systemctl_help(void) {
                "                         For kill, wait until service stopped\n"
                "     --no-block          Do not wait until operation finished\n"
                "     --no-wall           Don't send wall message before halt/power-off/reboot\n"
-               "     --message=MESSAGE   Specify human readable reason for system shutdown\n"
+               "     --message=MESSAGE   Specify human-readable reason for system shutdown\n"
                "     --no-reload         Don't reload daemon after en-/dis-abling unit files\n"
                "     --legend=BOOL       Enable/disable the legend (column headers and hints)\n"
                "     --no-pager          Do not pipe output into a pager\n"

src/systemd/sd-daemon.h

@@ -189,9 +189,9 @@ int sd_is_mq(int fd, const char *path);
                   that describes the daemon state. This is free-form
                   and can be used for various purposes: general state
                   feedback, fsck-like programs could pass completion
-                  percentages and failing programs could pass a human
+                  percentages and failing programs could pass a
-                  readable error message. Example: "STATUS=Completed
+                  human-readable error message. Example:
-                  66% of file system check..."
+                  "STATUS=Completed 66% of file system check..."
 
      NOTIFYACCESS=...
                   Reset the access to the service status notification socket.