Re: [PATCH] consequence: spawn

[Thorsten Wißmann <edu _at_ thorsten _minus_ wissmann _dot_ de>]

Hi Tylo,

On Wed, Dec 12, 2012 at 06:19:42PM -0800, Tyler Thomas Hart wrote:
> As requested by Wintervenom on archBBS (
> https://bbs.archlinux.org/viewtopic.php?id=128646&p=12 post#292 ), I
> implimented a spawn consquence when a rule is matched.

Yes. It's not the first time it is requested, e.g. there already was
something similar on the HLML[1]

> Since consequences are specified 'NAME'='VALUE', the command 'VALUE' is
> stored as a char*. There were two approaches to convert this into an
> exec-capable array. I included both patches, because I wasn't sure which
> one was ideal. Renammed to avoid ambiguity.

> One approach was to pass the string as a '-c' argument to /bin/sh using
> fork() and execl(). This is less code, but I don't know if /bin/sh is
> depended anywhere else in the source (although Im pretty sure 99.9999% of
> users are using a POSIX shell).

This creates a hard dependency to /bin/sh and assumes /bin/sh behaves
correctly for -c.

> The other approach was to parse the string using wordexp.h. Afaik this is a
> c standard lib, so I find it more elegant. But it pulls in more code.
> Converts the string to an array then fork()s and execvp()'s with this array.

IMO that's not an option because then you have to handle quoting with
different types of quotes "correctly".

One solution would be: Pipe it to an instance of $SHELL. I.e.

    char* sh = getenv("SHELL");
    FILE* f = popen(sh, "w");
    fprintf(f, "%s\n", command);
    fclose(f);

But then you still have to do a *lot* of error handling. Especially we
had to treat SIGPIPE correctly, otherwise hlwm would quit if $SHELL
quits before fprintf happens.

> Afaik, there are no side-effects to the wm when using this consequence. But
> I may have missed something in how the rule structs and routines work. Let
> me know if I missed anything.

It's very error prone: Consider the rule:

    hc rule instance=xterm spawn=xterm

This triggers an endless loop and lets hlwm/your session explode as soon
as the first xterm appears.

> Also, let me know if there is a better approach then the two above.

I'd prefer a consequence that emits a hook. Syntax: hook=NAME, so it
means, that a hook called "rule NAME" is emitted each time that rule is
triggered.

That means the user has to start a own daemon that listens to these
hooks and then reacts to it. It still has this problem of a endless
loop, but it can't be triggered easily.

And directly calling hlwm commands isn't a option because of the
parsing/quoting issues you already mentioned and because of the endless
loop problem.

So what do you think about the hook-consequence? And another open
question is, which hooks should be emitted for these rules if a new
window appears?

    hc rule hook=hook1
    hc rule hook=hook2 hook=hook3

Possible options are:

  - hook3
  - hook1, hook3
  - hook1, hook2, hook3

What's the most intuitive behaviour?

Regards,
Thorsten

[1] http://wwwcip.cs.fau.de/~re06huxa/herbstluftwm/archive/msg00048.html