Re: weird behavior with "[un]setopt monitor"

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 14,  9:34pm, Atom Smasher wrote:
}
} somewhat as expected:
}   % unsetopt monitor ; sleep 30 & ; setopt monitor
}   % jobs
}   [1]  + running    sleep 30
}   % kill %sleep
}   kill: kill %sleep failed: no such process

No, that's definitely not as expected.  The kill should have succeeded.
 
} not at all expected:
}   % unsetopt monitor ; sleep 30 & ; setopt monitor
}   % jobs
}   [1]  + running    sleep 30
}   % unsetopt monitor ; kill %sleep
}   % jobs

This, however, IS as expected.

} in the second case, i start "sleep 30" in the background after unsetting 
} the monitor option. after the job is dropped into the background, i reset 
} the monitor option. the job is listed in the jobs table, which i didn't 
} expect.

Jobs started with monitor turned off have always been in the job table,
because they have to be properly managed by the shell for purposes of
the "wait" command etc. even if you can't manipulate them with "fg" and
"bg".

Older zsh hid them from view, but would then lose track of details like
the job name, so when you turned monitor back on again "jobs" would
find them and produce a list of nameless processes.

There are still some oddities.  I don't recall exactly when jobs started
to be visible to "jobs" even with monitor turned off, but if they are
started when monitor is off they're impervious to ctrl+z (TSTP signals),
so if you turn monitor on again and bring them into the foreground, they
can't be stopped and re-backgrounded.

} as expected, it isn't killed in the normal way.

This is a bug.  Once you turn "monitor" back on, "kill" attempts to hit
jobs with killpg(pid, sig), equivalent to kill(-pid, sig), but because
the job was started with monitor turned off, it has no process group
and consequently killpg() fails even though the pid exists.

} the third example is where things really get weird. i start "sleep 30" in 
} the background after unsetting the monitor option. after the job is 
} dropped into the background, i reset the monitor option. the job is listed 
} in the jobs table, which i didn't expect. so far, the same as the second 
} example. but if after i unset the monitor option, i can kill the job with 
} kill. not at all what i expected.

With monitor off, zsh does kill(pid, sig) directly to stop only the
single process, regardless of whether the jobs were started with the
option turned on, so the right thing happens for jobs started without
monitor, but the wrong thing happens for jobs started with monitor.
This probably needs some attention; "kill" should do its work based
on the state of "monitor" at the time the job table entry was created,
not on the current state.

Bottom line, you're not guaranteed of predictable behavior unless you
change the monitor option only when the job table is empty.

} is this a bug or an undocumented feature?

It's a bug, but not the bug you think.

} it seems like an alternate table 
} to store jobs in, which is useful.

I'm not sure how you reached that conclusion, but it all depends on
whether the jobs are assigned to a process group.  Jobs started with
monitor off are never expected to have interaction with a terminal,
so they get no process group and ignore tty-generated signals.  All
jobs are in the same table, regardless.

It could be considered a bug that "fg" fails to ignore jobs that do
not have a process group.