* weird behavior with "[un]setopt monitor" @ 2009-03-14 8:34 Atom Smasher 2009-03-14 16:56 ` Bart Schaefer 0 siblings, 1 reply; 3+ messages in thread From: Atom Smasher @ 2009-03-14 8:34 UTC (permalink / raw) To: zsh-users as expected: % sleep 30 & [1] 47773 % jobs [1] + running sleep 30 % kill %sleep [1] + terminated sleep 30 somewhat as expected: % unsetopt monitor ; sleep 30 & ; setopt monitor % jobs [1] + running sleep 30 % kill %sleep kill: kill %sleep failed: no such process not at all expected: % unsetopt monitor ; sleep 30 & ; setopt monitor % jobs [1] + running sleep 30 % unsetopt monitor ; kill %sleep % jobs % in the first case, i start "sleep 30" in the background. it shows up in the jobs table, and can be killed as expected. no surprised there. 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. as expected, it isn't killed in the normal way. 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. is this a bug or an undocumented feature? it seems like an alternate table to store jobs in, which is useful. can i take advantage of this feature? or is it a bug that will be "fixed"? thanks... -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "I have presented factual data, statistical data, and projected data. Form your own conclusions. Perhaps the NSA has found a polynomial-time (read: fast) factoring algorithm. But we cannot dismiss an otherwise secure cryptosystem due to paranoia. Of course, on the same token, we cannot trust cryptosystems on hearsay or assumptions of security. Bottom line is this: in the field of computer security, it pays to be cautious. But it doesn't pay to be un-informed or needlessly paranoid. Know the facts." -- infiNity, The PGP Attack FAQ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: weird behavior with "[un]setopt monitor" 2009-03-14 8:34 weird behavior with "[un]setopt monitor" Atom Smasher @ 2009-03-14 16:56 ` Bart Schaefer 2009-03-14 18:22 ` Peter Stephenson 0 siblings, 1 reply; 3+ messages in thread From: Bart Schaefer @ 2009-03-14 16:56 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: weird behavior with "[un]setopt monitor" 2009-03-14 16:56 ` Bart Schaefer @ 2009-03-14 18:22 ` Peter Stephenson 0 siblings, 0 replies; 3+ messages in thread From: Peter Stephenson @ 2009-03-14 18:22 UTC (permalink / raw) To: zsh-users On Sat, 14 Mar 2009 09:56:40 -0700 Bart Schaefer <schaefer@brasslantern.com> wrote: > Bottom line, you're not guaranteed of predictable behavior unless you > change the monitor option only when the job table is empty. Indeed it's never really been set up to be a dynamic option at all, more as a way of querying whether a shell has job control, although turning it off at the start of a shell is probably consistent. This hasn't been documented, though. I can believe there are numerous oddities around if you start trying to turn it on and off. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-03-14 18:25 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-14 8:34 weird behavior with "[un]setopt monitor" Atom Smasher 2009-03-14 16:56 ` Bart Schaefer 2009-03-14 18:22 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).