This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Cannot get ^Z to suspend a program

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.


Original Message:
From: linda w \(cyg\)
Date: Tue, 11 Feb 2003 21:18:05 -0800
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
> 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?

Unsubscribe info:
Bug reporting:

mail2web - Check your email from the web at .

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]