[systemd-devel] [PATCH 2/2] man: use spaces instead of tabs

Jason St. John jstjohn at purdue.edu
Thu Feb 13 17:25:24 PST 2014


Several sections of the man pages included intermixed tabs and spaces;
this commit replaces all tabs with spaces.
---
 man/crypttab.xml             |  2 +-
 man/sd_bus_creds_get_pid.xml |  4 +--
 man/systemd-delta.xml        | 73 +++++++++++++++++++++-----------------------
 man/systemd.service.xml      | 48 +++++++++++++++--------------
 man/systemd.socket.xml       | 20 ++++++------
 5 files changed, 73 insertions(+), 74 deletions(-)

diff --git a/man/crypttab.xml b/man/crypttab.xml
index c563851..2d41500 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -305,7 +305,7 @@
 
                                 <listitem><para>Use TrueCrypt in system
                                 encryption mode. This implies
-				<varname>tcrypt</varname>.</para></listitem>
+                                <varname>tcrypt</varname>.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>
diff --git a/man/sd_bus_creds_get_pid.xml b/man/sd_bus_creds_get_pid.xml
index d335331..299c05a 100644
--- a/man/sd_bus_creds_get_pid.xml
+++ b/man/sd_bus_creds_get_pid.xml
@@ -385,7 +385,7 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
 
         <listitem><para>Given field is not available in
         <parameter>c</parameter>.</para>
-	</listitem>
+        </listitem>
       </varlistentry>
 
       <varlistentry>
@@ -399,7 +399,7 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
         <function>sd_bus_get_owner_uid</function> if the sender is not
         part of a systemd system unit, systemd user unit, systemd
         slice, logind session, or a systemd user session.</para>
-	</listitem>
+        </listitem>
       </varlistentry>
 
       <varlistentry>
diff --git a/man/systemd-delta.xml b/man/systemd-delta.xml
index ebaa349..7a34bbd 100644
--- a/man/systemd-delta.xml
+++ b/man/systemd-delta.xml
@@ -50,8 +50,8 @@
         <refsynopsisdiv>
                 <cmdsynopsis>
                         <command>systemd-delta</command>
-			<arg choice="opt" rep="repeat">OPTIONS</arg>
-			<arg choice="opt" rep="repeat"><replaceable>PREFIX</replaceable><optional>/<replaceable>SUFFIX</replaceable></optional>|<replaceable>SUFFIX</replaceable></arg>
+                        <arg choice="opt" rep="repeat">OPTIONS</arg>
+                        <arg choice="opt" rep="repeat"><replaceable>PREFIX</replaceable><optional>/<replaceable>SUFFIX</replaceable></optional>|<replaceable>SUFFIX</replaceable></arg>
                 </cmdsynopsis>
         </refsynopsisdiv>
 
@@ -78,27 +78,27 @@
                 the name of the main configuration file, must match).
                 For a fuller explanation, see
                 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
-		</para>
-
-		<para>The command line argument will be split into a
-		prefix and a suffix. Either is optional. The prefix
-		must be one of the directories containing
-		configuration files (<filename>/etc</filename>,
-		<filename>/run</filename>,
-		<filename>/usr/lib</filename>, ...). If it is given,
-		only overriding files contained in this directory will
-		be shown. Otherwise, all overriding files will be
-		shown. The suffix must be a name of a subdirectory
-		containing configuration files like
-		<filename>tmpfiles.d</filename>,
-		<filename>sysctl.d</filename> or
-		<filename>systemd/system</filename>. If it is given,
-		only configuration files in this subdirectory (across
-		all configuration paths) will be analyzed. Otherwise,
-		all configuration files will be analyzed. If the
-		commandline argument is not given at all, all
-		configuration files will be analyzed. See below for
-		some examples.</para>
+                </para>
+
+                <para>The command line argument will be split into a
+                prefix and a suffix. Either is optional. The prefix
+                must be one of the directories containing
+                configuration files (<filename>/etc</filename>,
+                <filename>/run</filename>,
+                <filename>/usr/lib</filename>, ...). If it is given,
+                only overriding files contained in this directory will
+                be shown. Otherwise, all overriding files will be
+                shown. The suffix must be a name of a subdirectory
+                containing configuration files like
+                <filename>tmpfiles.d</filename>,
+                <filename>sysctl.d</filename>, or
+                <filename>systemd/system</filename>. If it is given,
+                only configuration files in this subdirectory (across
+                all configuration paths) will be analyzed. Otherwise,
+                all configuration files will be analyzed. If the
+                command-line argument is not given at all, all
+                configuration files will be analyzed. See below for
+                some examples.</para>
         </refsect1>
 
         <refsect1>
@@ -200,25 +200,22 @@
                 </variablelist>
         </refsect1>
 
-	<refsect1>
-		<title>Examples</title>
+        <refsect1>
+                <title>Examples</title>
 
-		<para>To see all local configuration:</para>
-		<programlisting>systemd-delta
-		</programlisting>
+                <para>To see all local configuration:</para>
+                <programlisting>systemd-delta</programlisting>
 
-		<para>To see all runtime configuration:</para>
-		<programlisting>systemd-delta /run
-		</programlisting>
+                <para>To see all runtime configuration:</para>
+                <programlisting>systemd-delta /run</programlisting>
 
-		<para>To see all system unit configuration changes:</para>
-		<programlisting>systemd-delta systemd/system
-		</programlisting>
+                <para>To see all system unit configuration changes:</para>
+                <programlisting>systemd-delta systemd/system</programlisting>
 
-		<para>To see all runtime "drop-in" changes for system units:</para>
-		<programlisting>systemd-delta --type=extended /run/systemd/system
-		</programlisting>
-	</refsect1>
+                <para>To see all runtime "drop-in" changes for system units:</para>
+                <programlisting>systemd-delta --type=extended /run/systemd/system
+                </programlisting>
+        </refsect1>
 
         <refsect1>
                 <title>Exit status</title>
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 4693bec..7ac521a 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -756,29 +756,31 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
                                 status definitions can either be numeric
                                 exit codes or termination signal names,
                                 separated by spaces. For example:
-				<programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></programlisting>
-				ensures that exit codes 1, 2, 8 and
-				the termination signal
-				<constant>SIGKILL</constant> are
-				considered clean service terminations.
-			        </para>
-
-				<para>Note that if a process has a
-				signal handler installed and exits by
-				calling
-				<citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
-				in response to a signal, the
-				information about the signal is lost.
-				Programs should instead perform cleanup and kill themselves with the same signal instead. See
-				<ulink url="http://www.cons.org/cracauer/sigint.html">Proper handling of SIGINT/SIGQUIT — How to be a proper program</ulink>.</para>
-
-				<para>This option may appear more than once
-				in which case the list of successful
-				exit statuses is merged. If the empty
-				string is assigned to this option, the
-				list is reset, all prior assignments
-				of this option will have no
-				effect.</para></listitem>
+                                <programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></programlisting>
+                                ensures that exit codes 1, 2, 8, and
+                                the termination signal
+                                <constant>SIGKILL</constant> are
+                                considered clean service terminations.
+                                </para>
+
+                                <para>Note that if a process has a
+                                signal handler installed and exits by
+                                calling
+                                <citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+                                in response to a signal, the
+                                information about the signal is lost.
+                                Programs should instead perform cleanup
+                                and kill themselves with the same signal
+                                instead. See
+                                <ulink url="http://www.cons.org/cracauer/sigint.html">Proper handling of SIGINT/SIGQUIT — How to be a proper program</ulink>.</para>
+
+                                <para>This option may appear more than once,
+                                in which case the list of successful
+                                exit statuses is merged. If the empty
+                                string is assigned to this option, the
+                                list is reset, and all prior assignments
+                                of this option will have no
+                                effect.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 946c30a..724f54f 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -121,16 +121,16 @@
                 boot or late system shutdown should disable this
                 option.</para>
 
-		<para>Socket units will have a
-		<varname>Before=</varname> dependency on the service
-		which they trigger added implicitly. No implicit
-		<varname>WantedBy=</varname> or
-		<varname>RequiredBy=</varname> dependency from the
-		socket to the service is added. This means that the
-		service may be started without the socket, in which
-		case it must be able to open sockets by itself. To
-		prevent this, an explicit <varname>Requires=</varname>
-		dependency may be added.</para>
+                <para>Socket units will have a
+                <varname>Before=</varname> dependency on the service
+                which they trigger added implicitly. No implicit
+                <varname>WantedBy=</varname> or
+                <varname>RequiredBy=</varname> dependency from the
+                socket to the service is added. This means that the
+                service may be started without the socket, in which
+                case it must be able to open sockets by itself. To
+                prevent this, an explicit <varname>Requires=</varname>
+                dependency may be added.</para>
 
                 <para>Socket units may be used to implement on-demand
                 starting of services, as well as parallelized starting
-- 
1.8.5.4



More information about the systemd-devel mailing list