From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20877 invoked from network); 30 Sep 2008 18:00:25 -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,WEIRD_PORT autolearn=no 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; 30 Sep 2008 18:00:25 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 87165 invoked from network); 30 Sep 2008 18:00:13 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 30 Sep 2008 18:00:13 -0000 Received: (qmail 21310 invoked by alias); 30 Sep 2008 18:00:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25780 Received: (qmail 21288 invoked from network); 30 Sep 2008 17:59:58 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 30 Sep 2008 17:59:58 -0000 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by bifrost.dotsrc.org (Postfix) with ESMTP id F399C8030847 for ; Tue, 30 Sep 2008 19:59:45 +0200 (CEST) Received: by wa-out-1112.google.com with SMTP id m28so83491wag.29 for ; Tue, 30 Sep 2008 10:59:44 -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 :content-transfer-encoding:content-disposition:references; bh=/7wBDP/6SfsXh1FcAKtb0I4fv7pbs0cxzfdrHeklS/I=; b=EvX8V9EvMbmpfWDjw2zGQBCbYPikq5XBt0ufEew2MGQ6+yrqY0wbTb4xWBriG2LKGD PVd01lFn5594aDUdrL/25q6CEVotpjQQlpYKol8PWarD8WPArIHtAdpGBCih2CC7Dflz U6lrdxIQ/GGNb6oGcs5FOCjQe7wN3/po2j4lg= 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:content-transfer-encoding:content-disposition :references; b=S15jSVddF5hewMH9F+OBJU5OZF+UudHgNvU4dRmGR3mvL729b2T/yPqfoOOA4yhfS1 zHu1H+yIju0YVwBMw4ZLq5Xr10/qa45c1EigU9xiqnNhypeapau3gVEfp/SQjYiU+dQY VSVTVDf124LLsNZX5Rqj917Ab7FUT9brCshJM= Received: by 10.114.149.2 with SMTP id w2mr7989649wad.92.1222797583979; Tue, 30 Sep 2008 10:59:43 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Tue, 30 Sep 2008 10:59:43 -0700 (PDT) Message-ID: <6cd6de210809301059o64216c18wfb69491c5ff7b049@mail.gmail.com> Date: Tue, 30 Sep 2008 13:59:43 -0400 From: "Rocky Bernstein" To: "Peter Stephenson" Subject: Re: Help me track down a tough bug? (probably funcfiletrace, subshells and possibly I/O redirection) Cc: "Zsh hackers list" In-Reply-To: <20080930175300.2e93fabf@news01> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6cd6de210809281219i4bf1ed18mefa45b967fa835a6@mail.gmail.com> <6cd6de210809281932u2e04a844l219d1db5a7568a73@mail.gmail.com> <20080929095201.451381d0@news01> <6cd6de210809290411m60cb669bk3817d768adce378a@mail.gmail.com> <200809291125.m8TBPsQM005256@news01.csr.com> <6cd6de210809290711j12363e1bo159e1739bae7b2fd@mail.gmail.com> <200809291425.m8TEPSoR007204@news01.csr.com> <20080929224209.1bd8f3f6@pws-pc> <6cd6de210809291718n2fa49590q42eaec499d106284@mail.gmail.com> <20080930175300.2e93fabf@news01> X-Virus-Scanned: ClamAV 0.92.1/8361/Tue Sep 30 16:28:47 2008 on bifrost X-Virus-Status: Clean My mistake. You are correct. This bug was introduced in paring down the program and removing an initial truncate output (leaving the subsequent append outputs). And I now see the answer to why output was disappearing in the subshell which was my initial concern. Thanks for all the help! Any thoughts on marking subshell level inside one of the stack traces or having return inside trap DEBUG with a negative number cause an immediate return? Thanks again. On Tue, Sep 30, 2008 at 12:53 PM, Peter Stephenson wrote: > On Mon, 29 Sep 2008 20:18:52 -0400 > "Rocky Bernstein" wrote: >> zshdb<3> p ${funcfiletrace[@]} >> >> ./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96 >> ./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34 >> ./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96 >> ./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34 >> ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34 >> # Were did that double set of lines come from? > > Hmmm... I'm not convinced this has got anything directly to do with the > shell rather than the debugger. Here's what I get when I simply ask for > the PID repeated times: > > --------------- > ./zshdb2.sh:7 ./zshdb2.sh:34 > =============== > (./zshdb2.sh:34): > . ./testing.sh > ./zshdb2.sh:9 ./zshdb2.sh:34 > zshdb<1> p $$ > 711 > ./zshdb2.sh:9 ./zshdb2.sh:34 > zshdb<2> p $$ > 711 > 711 > ./zshdb2.sh:9 ./zshdb2.sh:34 > zshdb<3> p $$ > 711 > 711 > 711 > ./zshdb2.sh:9 ./zshdb2.sh:34 > zshdb<4> > > It looks like something is odd with whatever is holding the command to be > executed. You know better than me how that works. Sorry you are correct. This bug was introduced in paring down the program. Line 6 of lib/eval.sh should be: print "$@" > $_Dbg_evalfile rather than print "$@" >> $_Dbg_evalfile However after this is fixed we have the disappearing output when in that 2nd set of subshells which is the problem that motivated all of this. What you want to print or eval is written to _Dbg_evalfile along with some other commands to try to simulate the environment you were in before entering the debugger. Then that file is sourced via: if [[ -t $_Dbg_fdi ]] ; then _Dbg_set_dol_q $_Dbg_debugged_exit_code . $_Dbg_evalfile >&${_Dbg_fdi} else _Dbg_set_dol_q $_Dbg_debugged_exit_code . $_Dbg_evalfile fi Somehow in that context no output appears even though output may be explicitly written to a terminal file descriptor in the first branch. I've also have tried using just the "else" branch above and still no output. Finally, you can remove the call to _Dbg_set_dol_q which is just setting $? before source'ing the file and that still doesn't cause output to reappear. So there seems to be something funky with I/O inside a backtick subshell. I don't get that problem inside a () subshell, even if output has been redirected on that, e.g. ( x=1)>/dev/null because the debugger output goes to _Dbg_fdi. > -- > Peter Stephenson Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 >