* 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.
* 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.
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=
* 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.
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
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.
* **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
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>
<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>
<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>
- should be a short human readable string identifying the reason why the lock is taken. Finally,
+ 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,
<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
<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>
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
<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
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>
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>.
<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
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>
<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
<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>
<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>
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;
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);
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
- * os-release(5) fields). Precise is preferred over vague, and human readable over machine
+ /* 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
* readable. Thus:
*
* 1. First priority gets the PRETTY_NAME field, which is the primary string intended for display,
* 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)
*
/* 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 */
" 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"
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
- readable error message. Example: "STATUS=Completed
- 66% of file system check..."
+ percentages and failing programs could pass a
+ human-readable error message. Example:
+ "STATUS=Completed 66% of file system check..."
NOTIFYACCESS=...
Reset the access to the service status notification socket.