vmon: interpolate command execution arguments

This adds runtime expansion of the executed command's argv, to
support things like passing the vmon X window id to the executed
command, session name, and output dir.

Format specifiers currently supported by this commit:

 %W	X window id for vmon in hexadecimal
 %n	verbatim name supplied via --name
 %N	filename-safe variant of name supplied via --name
 %O	output directory supplied via --output-dir (or ".")
 %%	literal %

There's not curerrently any escaping syntax implemented, relying
entirely on %-stuffing to escape interpolation. i.e. use %%N to
express %N post-interpolation.

This commit also adds SIGINT and SIGQUIT handlers when executing
a command.  The first such signal received is simply propagated
to the child command's process, which upon exiting will trigger
the existing SIGCHLD behavior (snapshot if requested, exit).

If a subsequent repeated SIGINT or SIGQUIT is received, an abrupt
exit is performed without waiting for SIGCHLD or otherwise
synchronizing with the child process.

The impetus for this is to enable running recordMyDesktop
alongside the executed command to record the vmon window while
running things like benchmarks or other high-level profiling/CPU
usage over time observations.

The recordMyDesktop utility already responds to SIGINT for ending
a recording, so SIGINT propagation should be sufficient for
recording vmon sessions - provided the recordMyDesktop process is
positioned to receive signals in the executed command.  i.e. is
the foreground process or session leader if executed via
something like a `/bin/bash -c` construction.

Some effort has been made to ensure the vmon window is mapped
before running the executed command (XMapWindow() && XSync()).
But with SubstructureRedirect in play, as when a window manager
is active, this alone isn't sufficient to ensure the window is
actually mapped and viewable.

This poses a problem with for the current `recordMyDesktop
--windowid` implementation, which hard fails when the specified
window isn't already mapped and visible.  Depending on who wins
the race, the window may not yet actually be mapped by the window
manager by the time recordMyDesktop queries its attributes.  But
this is something to fix in recordMyDesktop, even if vmon waited
for a MapNotify event before executing the command, the window
could become unmapped by the window manager - or maybe it
wouldn't even become mapped in a timely fashion if it's placed on
a hidden virtual desktop at the time.  The recording tool needs
to just be more robust in this regard, and should really follow
the window around anyways, as well as do things like maybe pause
the recording when unmapped, etc.  Out of scope for vmon.

The aforementioned `recordMyDesktop --windowid` race has been
filed as an issue @
https://github.com/recordmydesktop/recordmydesktop/issues/7

0 files changed, 0 insertions, 0 deletions