man: do not index various /foobar/ paths

For #17177.

man/environment.d.xml

@@ -76,7 +76,7 @@
         <title>Setup environment to allow access to a program installed in
         <filename index="false">/opt/foo</filename></title>
 
-        <para><filename>/etc/environment.d/60-foo.conf</filename>:
+        <para><filename index="false">/etc/environment.d/60-foo.conf</filename>:
         </para>
         <programlisting>
         FOO_DEBUG=force-software-gl,log-verbose

man/systemd-hibernate-resume-generator.xml

@@ -49,7 +49,7 @@
 
         <listitem><para>Takes a path to the resume device. Both
         persistent block device paths like
-        <filename>/dev/disk/by-foo/bar</filename> and
+        <filename index="false">/dev/disk/by-foo/bar</filename> and
         <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-style
         specifiers like <literal>FOO=bar</literal> are
         supported.</para></listitem>

man/systemd-homed.service.xml

@@ -86,9 +86,9 @@
     <para>In order to migrate a home directory from a host <literal>foobar</literal> to another host
     <literal>quux</literal> it is hence sufficient to copy
     <filename>/var/lib/systemd/home/local.public</filename> from the host <literal>foobar</literal> to
-    <literal>quux</literal>, maybe calling the file on the destination
+    <literal>quux</literal>, maybe calling the file on the destination <filename
-    <filename>/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the user
+    index="false">/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the
-    record should be modifiable on <literal>quux</literal> the pair
+    user record should be modifiable on <literal>quux</literal> the pair
     <filename>/var/lib/systemd/home/local.public</filename> and
     <filename>/var/lib/systemd/home/local.private</filename> need to be copied from <literal>foobar</literal>
     to <literal>quux</literal>, and placed under the identical paths there, as currently only a single

man/systemd-nspawn.xml

@@ -348,16 +348,17 @@
         terminated. When the mode parameter is specified as <option>no</option> (the default), the whole OS tree is
         made available writable (unless <option>--read-only</option> is specified, see above).</para>
 
-        <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system (or
+        <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system
-        <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the hierarchy are
+        (or <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the
-        unaffected — regardless if they are established automatically (e.g. the EFI system partition that might be
+        hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system
-        mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or explicitly (e.g. through an additional
+        partition that might be mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or
-        command line option such as <option>--bind=</option>, see below). This means, even if
+        explicitly (e.g. through an additional command line option such as <option>--bind=</option>, see
-        <option>--volatile=overlay</option> is used changes to <filename>/efi/</filename> or
+        below). This means, even if <option>--volatile=overlay</option> is used changes to
-        <filename>/boot/</filename> are prohibited in case such a partition exists in the container image operated on,
+        <filename>/efi/</filename> or <filename>/boot/</filename> are prohibited in case such a partition
-        and even if <option>--volatile=state</option> is used the hypothetical file <filename>/etc/foobar</filename> is
+        exists in the container image operated on, and even if <option>--volatile=state</option> is used the
-        potentially writable if <option>--bind=/etc/foobar</option> if used to mount it from outside the read-only
+        hypothetical file <filename index="false">/etc/foobar</filename> is potentially writable if
-        container <filename>/etc</filename> directory.</para>
+        <option>--bind=/etc/foobar</option> if used to mount it from outside the read-only container
+        <filename>/etc</filename> directory.</para>
 
         <para>The <option>--ephemeral</option> option is closely related to this setting, and provides similar
         behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details,

man/systemd.exec.xml

@@ -1275,7 +1275,7 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
 
         <para>Example: if a system service unit has the following,
         <programlisting>RuntimeDirectory=foo/bar baz</programlisting>
-        the service manager creates <filename>/run/foo</filename> (if it does not exist),
+        the service manager creates <filename index='false'>/run/foo</filename> (if it does not exist),
 
         <filename index='false'>/run/foo/bar</filename>, and <filename index='false'>/run/baz</filename>. The
         directories <filename index='false'>/run/foo/bar</filename> and

man/systemd.service.xml

@@ -1307,7 +1307,7 @@ ls</programlisting>
       <title>Simple service</title>
 
       <para>The following unit file creates a service that will
-      execute <filename>/usr/sbin/foo-daemon</filename>. Since no
+      execute <filename index="false">/usr/sbin/foo-daemon</filename>. Since no
       <varname>Type=</varname> is specified, the default
       <varname>Type=</varname><option>simple</option> will be assumed.
       systemd will assume the unit to be started immediately after the

man/systemd.special.xml

@@ -862,8 +862,8 @@
           pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be
           part of any transaction unless a storage daemon is used. The instance name for instances of this
           template unit must be a properly escaped block device node path, e.g.
-          <filename>blockdev@dev-mapper-foobar.target</filename> for the storage device
+          <filename index="false">blockdev@dev-mapper-foobar.target</filename> for the storage device
-          <filename>/dev/mapper/foobar</filename>.</para></listitem>
+          <filename index="false">/dev/mapper/foobar</filename>.</para></listitem>
         </varlistentry>
         <varlistentry>
           <term><filename>cryptsetup-pre.target</filename></term>

man/systemd.unit.xml

@@ -279,7 +279,7 @@
     <para>When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the
     root directory <literal>/</literal> is encoded as single dash <literal>-</literal>. In addition, any leading,
     trailing or duplicate <literal>/</literal> characters are removed from the string before transformation. Example:
-    <filename>/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
+    <filename index="false">/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
 
     <para>This escaping is fully reversible, as long as it is known whether the escaped string was a path (the
     unescaping results are different for paths and non-path strings). The
@@ -1922,7 +1922,7 @@ ExecStart=/usr/sbin/foo-daemon
 
       <para>After running <command>systemctl enable</command>, a
       symlink
-      <filename>/etc/systemd/system/multi-user.target.wants/foo.service</filename>
+      <filename index="false">/etc/systemd/system/multi-user.target.wants/foo.service</filename>
       linking to the actual unit will be created. It tells systemd to
       pull in the unit when starting
       <filename>multi-user.target</filename>. The inverse