generators: accept one or three args, do not write to /tmp

Since the general generator logic was established in the rewrite in
07719a21b6425d378b36bb8d7f47ad5ec5296d28, generators would always write to /tmp
by default. I think this not a good default at all, because generators write a
bunch of files and would create a mess in /tmp. And for debugging, one
generally needs to remove all the files in the output directory, because
generators will complain in the output paths are already present. Thus the
approach of disabling console logging and writing many files to /tmp when
invoked with no arguments is not nice, so let's disallow operation with no
args.

But when debugging, one generally does not care about the separate output dirs
(most generators use only one). Thus the general pattern I use is something
like:
  rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/{x,x,x}
This commit allows only one directory to be specified and simplifies this to:
  rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/x

1 files changed, 11 insertions, 10 deletions

diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml
index 1f916ac65e..d837afb6f9 100644
--- a/man/systemd.generator.xml
+++ b/man/systemd.generator.xml
@@ -26,8 +26,8 @@
     <cmdsynopsis>
       <command index='false'>/path/to/generator</command>
       <arg choice="plain"><replaceable>normal-dir</replaceable></arg>
-      <arg choice="plain"><replaceable>early-dir</replaceable></arg>
-      <arg choice="plain"><replaceable>late-dir</replaceable></arg>
+      <arg choice="option"><replaceable>early-dir</replaceable></arg>
+      <arg choice="option"><replaceable>late-dir</replaceable></arg>
     </cmdsynopsis>
 
     <para>
@@ -56,13 +56,13 @@
     that they can extend the unit file hierarchy the service manager subsequently loads and operates
     on.</para>
 
-    <para>Each generator is called with three directory paths that are to be used for generator output. In
-    these three directories, generators may dynamically generate unit files (regular ones, instances, as well
-    as templates), unit file <filename>.d/</filename> drop-ins, and create symbolic links to unit files to
-    add additional dependencies, create aliases, or instantiate existing templates. Those directories are
-    included in the unit load path of
-    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, allowing
-    generated configuration to extend or override existing definitions.</para>
+    <para><command>systemd</command> will call each generator with three directory paths that are to be used
+    for generator output. In these three directories, generators may dynamically generate unit files (regular
+    ones, instances, as well as templates), unit file <filename>.d/</filename> drop-ins, and create symbolic
+    links to unit files to add additional dependencies, create aliases, or instantiate existing templates.
+    Those directories are included in the unit load path, allowing generated configuration to extend or
+    override existing definitions. For tests, generators may be called with just one argument; the generator
+    should assume that all three paths are the same in that case.</para>
 
     <para>Directory paths for generator output differ by priority: <filename>…/generator.early</filename> has
     priority higher than the admin configuration in <filename>/etc/</filename>, while
@@ -96,7 +96,8 @@
     <para>Generators are invoked with three arguments: paths to directories where generators can place their
     generated unit files or symlinks. By default those paths are runtime directories that are included in the
     search path of <command>systemd</command>, but a generator may be called with different paths for
-    debugging purposes.</para>
+    debugging purposes. If only one argument is provided, the generator should use the same directory as the
+    the three output paths.</para>
 
     <orderedlist>
       <listitem>