A tail of two situations

[Jeremy Mates <jeremy.mates@xxxxxxxxx>]

If MONITOR is set in ZSH, and control+c issued, the subsequent command
*is not* run:

  % tail -n0 -f /etc/passwd; echo foo
  ^C
  %

However! If tail is modified to handle SIGINT, and quits via errx(3)
or the like:

  void polonius_polka(int sig)
  {
    errx(1, "oh I am slain"); // 128+sig does not replicate "err by sig"
  }

the subsequent command *is* run:

  % tail -n0 -f /etc/passwd; echo foo
  ^Ctail: oh I am slain
  foo
  %

This seems inconsistent, as the behavior deep within ZSH (with MONITOR
set) depends on how(if) the program handles the ^C. Consistency in ZSH
demands either `unsetopt MONITOR` (subsequent code never run), or using
a subshell and trapping INT via a "function trap" (subsequent code run):

  % ( TRAPINT(){}; tail -n0 -f /etc/passwd ); echo foo
  ^Cfoo
  % 

(But not the "list trap" `trap '' INT`, as that causes ZSH to ignore the
SIGINT, and pass that ignore down to tail, unless disabling control+c
is for some reason desired.)

Spelunking Src/jobs.c and Src/signals.c reveals that in either case
(`tail` having a signal handler or not), ZSH receives a SIGCHLD, and
that the only apparent difference is the contents of the "status" int
populated by the wait(2) call, which eventually reaches the

    /* When MONITOR is set, the foreground process runs in a different *
     * process group from the shell, so the shell will not receive     *
     * terminal signals, therefore we pretend that the shell got       *
     * the signal too.                                                 */
    if (inforeground == 2 && isset(MONITOR) && WIFSIGNALED(status)) {
        int sig = WTERMSIG(status);

block of code in Src/jobs.c, and then for the tail-with-no-signal-
handler case the code sets `breaks = loops; errflag = 1`, wanders into
check_cursh_sig(), which does nothing in this case, and then the code
returns to who knows where. Something in that subsequent code then does
not run the `; echo foo` code. However, I do not know where that code
is, and do not know whether changing it would cause any other
ramifications. It might be nice to have consistent behavior, though
there is a workaround of either unsetting MONITOR, or using a
subshell/TRAPINT function.