From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 533 invoked from network); 11 Sep 2008 15:59:53 -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,HTML_MESSAGE 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; 11 Sep 2008 15:59:53 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 61132 invoked from network); 11 Sep 2008 15:59:34 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 Sep 2008 15:59:34 -0000 Received: (qmail 20391 invoked by alias); 11 Sep 2008 15:59:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25648 Received: (qmail 20365 invoked from network); 11 Sep 2008 15:59:20 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 11 Sep 2008 15:59:20 -0000 Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by bifrost.dotsrc.org (Postfix) with ESMTP id 977F1802710A for ; Thu, 11 Sep 2008 17:59:12 +0200 (CEST) Received: by gxk12 with SMTP id 12so16495494gxk.21 for ; Thu, 11 Sep 2008 08:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=RwI2KrNxwucfyeKVbS2EjOynGLHcFk1LlFiIGkv2ft0=; b=KQktsinuWSSefDbfD/7BsgcmHJELi+EZ6r+leVQ7LSWO1Y0LU7okrFQ7x32Y/9JzMq tskixew3MelokNea4idFicZ5juS0jjy97UfMQggfz+w6Xv6CYAceb04ndP5aL5zYeZaS 0iXNenwyXJ5IVDyGOHWBPnT2cwe0irCI1wHWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=iL/44lYuPYos5MCkJla6hm3mZ3bNKhOkINGIH0ep3T3Iu+JvMso2izwoSaHuWWU08S rxn91Qwt8BYghkbuUBRFxZ/XK9G73Y0ltmM/mSMh2Rjfg2bz87p9JQkWjfcJfh/oCucb NUU6fPAEqye5GG79C+v3418ck6Uf14BsXLDF8= Received: by 10.114.158.1 with SMTP id g1mr2230520wae.111.1221148749369; Thu, 11 Sep 2008 08:59:09 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Thu, 11 Sep 2008 08:59:09 -0700 (PDT) Message-ID: <6cd6de210809110859n1caa4754o9f5dd0b905e48ae0@mail.gmail.com> Date: Thu, 11 Sep 2008 11:59:09 -0400 From: "Rocky Bernstein" To: "Peter Stephenson" Subject: Re: preventing the leading space in process substitution Cc: "Zsh Hackers' List" In-Reply-To: <20080911155416.643a84d3@news01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14474_16939463.1221148749368" References: <20080909144101.GA30693@lapse.rw.madduck.net> <080910074842.ZM19151@torch.brasslantern.com> <200809101510.m8AFAajX007203@news01.csr.com> <080910090554.ZM19272@torch.brasslantern.com> <6cd6de210809101151q4d0a2a35p452fe656e0ee7dd5@mail.gmail.com> <20080911130005.7c5e2b7c@news01> <6cd6de210809110544u569838dk5a93a739fa267822@mail.gmail.com> <20080911140505.6c040bf4@news01> <080911073531.ZM24010@torch.brasslantern.com> <20080911155416.643a84d3@news01> X-Virus-Scanned: ClamAV 0.92.1/8217/Thu Sep 11 14:12:16 2008 on bifrost X-Virus-Status: Clean ------=_Part_14474_16939463.1221148749368 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Sep 11, 2008 at 10:54 AM, Peter Stephenson wrote: > On Thu, 11 Sep 2008 07:35:31 -0700 > Bart Schaefer wrote: > > } I can't see why we shouldn't keep the debug-related traps, ZERR and > > } DEBUG, alive in subshells. > > > > I can't think of any reason either, unless maybe there are cases where > > it could result in the trap being executed in both the subshell and > > the parent. > > Shouldn't normally happen, but I suppose we'll just have to see. I've > committed the patch. > > That's to say, "(echo foo)" causes a DEBUG trap for the (...) itself, and > then a DEBUG trap for any contents inside the subshell according to the > normal rules for a list of commands, but I think that's exactly what we > want (it's the same as for {...}). Seems to do exactly the right thing. Thanks! > > I note that $ZSH_DEBUG_CMD has strange (overlarge) indentation for the > elements of (...) after the opening parenthesis. I think that needs > revisiting. I don't quite understand why the default indentation is 1 > instead of 0; obviously that's right for outputting the bodies of > functions, but the code has many other uses. > > -- > Peter Stephenson Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ------=_Part_14474_16939463.1221148749368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Thu, Sep 11, 2008 at 10:54 AM, Peter Stephenson <pws@csr.com> wrote:
On Thu, 11 Sep 2008 07:35:31 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } I can't see why we shouldn't keep the debug-related traps, ZERR and
> } DEBUG, alive in subshells.
>
> I can't think of any reason either, unless maybe there are cases where
> it could result in the trap being executed in both the subshell and
> the parent.

Shouldn't normally happen, but I suppose we'll just have to see.  I've
committed the patch.

That's to say, "(echo foo)" causes a DEBUG trap for the (...) itself, and
then a DEBUG trap for any contents inside the subshell according to the
normal rules for a list of commands, but I think that's exactly what we
want (it's the same as for {...}).

Seems to do exactly the right thing. Thanks!




I note that $ZSH_DEBUG_CMD has strange (overlarge) indentation for the
elements of (...)  after the opening parenthesis.  I think that needs
revisiting.  I don't quite understand why the default indentation is 1
instead of 0; obviously that's right for outputting the bodies of
functions, but the code has many other uses.

--
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

------=_Part_14474_16939463.1221148749368--