* 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).