From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17300 invoked from network); 6 Sep 2008 21:24:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 6 Sep 2008 21:24:16 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 78305 invoked from network); 6 Sep 2008 21:23:55 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 Sep 2008 21:23:55 -0000 Received: (qmail 3140 invoked by alias); 6 Sep 2008 21:23:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25629 Received: (qmail 3122 invoked from network); 6 Sep 2008 21:23:42 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 Sep 2008 21:23:42 -0000 Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by bifrost.dotsrc.org (Postfix) with ESMTP id 71CA4802710A for ; Sat, 6 Sep 2008 23:23:39 +0200 (CEST) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080906212338.XFJR777.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Sat, 6 Sep 2008 22:23:38 +0100 Received: from pws-pc ([81.107.43.40]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20080906212338.JUVA29597.aamtaout03-winn.ispmail.ntl.com@pws-pc> for ; Sat, 6 Sep 2008 22:23:38 +0100 Date: Sat, 6 Sep 2008 22:23:27 +0100 From: Peter Stephenson To: "Zsh hackers list" Subject: Re: Request: a way to get the subshell level nesting Message-ID: <20080906222327.28e89ba3@pws-pc> In-Reply-To: <6cd6de210809051436l5b9d212fl62eabd07af277943@mail.gmail.com> References: <6cd6de210809050711h4811efei413630fb514333ae@mail.gmail.com> <20080905214529.254cd16f@pws-pc> <6cd6de210809051436l5b9d212fl62eabd07af277943@mail.gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8175/Sat Sep 6 20:56:57 2008 on bifrost X-Virus-Status: Clean On Fri, 5 Sep 2008 17:36:37 -0400 "Rocky Bernstein" wrote: > In a program such > as bashdb when a "quit" is done we may really need to quit several levels of > shells that may have gotten invoked in between. > Suppose you were writing a debugger for GNU Make. You'd have the same issue. > Or any program > that might call itself recursively and you don't have control in between of > how many *other* recursive shell invocations might have gone on. > > So here we need the actual number counting whatever optimization was done, > not the virtual number of shells. And here I don't think it too bad to have > the user aware that an optimization was done. When one debugs optimized C > code in gcc there are corresponding issues that any competent programmer > just needs to be aware of. Like in-lined functions or statements which > appear out of order because that's the way assembly code was reorganized. We'll have to see how this works out; I'm hoping that in fact any time the debugger is hanging around the subshell won't be optimized out and the question doesn't arise. However, if you encounter oddities we can certainly look at this again. The trade off between expectation and reality can be a bit elastic down here. pws