Mail Archives: cygwin/2003/02/12/11:23:51
Job control and signals for Cygwin processes are areas pretty
internal to Cygwin. they are also pretty complex. IMO, it's
hard to talk much about adding some feature to them without the
context of what's already there. If you can put your suggestions
in that context, I expect you'll get better feedback. Even if that's
not the case, you'll be in a better position to evaluate your own
ideas given the current architecture.
Just my $.02.
Larry
Original Message:
-----------------
From: linda w \(cyg\) cygwin AT tlinx DOT org
Date: Tue, 11 Feb 2003 21:18:05 -0800
To: cygwin AT cygwin DOT com
Subject: RE: Cannot get ^Z to suspend a program
> Sure, but those programs hook the key(s) in a global fashion,
> not just
> from individual programs. So, Cygwin could hook the Ctrl+Z key, but
> what would it do then, how would it know which process to suspend?
>
> I'm not sure that cygwin could 'suspend' a non-cygwin process
> even if it
> wanted to.
---
started playing around with this...I note:
> cygjob& kill -STOP %1 #works as expected
but
> winprog& kill -STOP %1 #laughs at my puny attempts to stop it
So cygjobs seem to be suspendable but winjobs are already
not playing fair!
now I try this:
> while :; do sleep 3; echo 1;done # control-z ignored
Also, though, I note that if I type while the program is running, say
"ls", then press control-c, "ls" still executes!
Under lnx, I see the 'ls' characters echoed as soon as I type them --
it appears "readline" is running "in foreground" even though I have
a "job" (the while loop) running in foreground as well. It's "like"
even when a foreground job is running, there is a 2nd, system level
process that also runs and processes key presses (allowing processing
control-u and control-r, among other, readline functions).
It _seems_ like to get similar functionality on cygwin, one might
have to have the same -- perhaps a unix-like fork/exec/wait would
translate, internally, to a windows "fork/exec/select", where select
waits for keyboard input or the child process to end. Then the win-parent
process -- still in control, could process line editing and user-job
control key presses -- since we know that, at least, cygwin programs
are "well behaved" in regards to "respecting" a "kill -STOP", the
win-parent "keyboard monitor thread" could use the same means to
STOP a child.
As for job control of winjobs? Guess that'd be another whole pain
in the butt. Though maybe if the running user has 'debug' privs, they
could attach the process and suspend it that way? (Dunno) If their
could be some way of suspending winjobs, though, then the above 'keyboard
thread' method could be used to implement job control.
Wha'd'ya think?
-linda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -