Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "linda w \(cyg\)" To: Subject: RE: Cannot get ^Z to suspend a program Date: Wed, 12 Feb 2003 12:10:40 -0800 Message-ID: <001901c2d2d2$d0d09190$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <184670-220032312162339677@M2W029.mail2web.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal > 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. --- I'm familiar with that logic, however, in a 'design' phase, it's sometimes useful to forget about "what is" and only look at the "end result" of what is wanted. If one limits one's thinking based on the current design, one might never come up with ideas that would be precluded by the current design. It's more of a "wish list" exercise than a request to actually go "fix" something so that if someone was working on those areas or did in the not too distant future, they could, perhaps, be mindful of what might be, desirable, behavior. It's like that saying about "when your are up to your neck in alligators, its difficult to remember that your original objective was to drain the swamp". :-) -l -- 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/