From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10855 invoked from network); 29 Sep 2008 11:12:03 -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; 29 Sep 2008 11:12:03 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 11710 invoked from network); 29 Sep 2008 11:11:54 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 29 Sep 2008 11:11:54 -0000 Received: (qmail 6244 invoked by alias); 29 Sep 2008 11:11:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25767 Received: (qmail 6224 invoked from network); 29 Sep 2008 11:11:45 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 29 Sep 2008 11:11:45 -0000 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by bifrost.dotsrc.org (Postfix) with ESMTP id C536F8030847 for ; Mon, 29 Sep 2008 13:11:36 +0200 (CEST) Received: by wa-out-1112.google.com with SMTP id m28so1073411wag.29 for ; Mon, 29 Sep 2008 04:11:35 -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=MECH+UzNcSLxrvWpCymXeDBLglf6XCSwfpVPWzdl+go=; b=eNUGVUV+nkQNGKgjSdKkaAxwtWHrFsyI66Cdx2ylMBz0NuFO5jFZizzQCm0E5uLEHP QoZgY490f8jgh4gsMIq0qYyQUMFAeD0kXDsRnWKLbEgIJ1DUhmTP/eQ+pehpwmgSD9s7 9FPWHPLhl60E4DLgWqVx4LUVHbk6IKBL1B4NE= 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=bqO4YdXUuUKSA7Ax1PYEtaC8yUrwnaPDeNBpW+Zm1X+9u7GS2ifhfC8dJqAOVVEqgh d4BfYu/ufC4tIe+OgMpN6IgKQnkiD2tFaSsPykYRWDUngQ2CEUFr8EE9Gjzg9gHh8z8i in90xNkymUmwUsY97XV3D7f6FmbiYIJaxBctw= Received: by 10.115.94.1 with SMTP id w1mr5500497wal.90.1222686695027; Mon, 29 Sep 2008 04:11:35 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Mon, 29 Sep 2008 04:11:34 -0700 (PDT) Message-ID: <6cd6de210809290411m60cb669bk3817d768adce378a@mail.gmail.com> Date: Mon, 29 Sep 2008 07:11:34 -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: <20080929095201.451381d0@news01> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23648_18430414.1222686695028" References: <6cd6de210809281219i4bf1ed18mefa45b967fa835a6@mail.gmail.com> <20080928221651.6ee7f671@pws-pc> <6cd6de210809281932u2e04a844l219d1db5a7568a73@mail.gmail.com> <20080929095201.451381d0@news01> X-Virus-Scanned: ClamAV 0.92.1/8353/Mon Sep 29 11:57:09 2008 on bifrost X-Virus-Status: Clean ------=_Part_23648_18430414.1222686695028 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks. This addresses one of the problem seen. There are still the others -- output disappearing and weird line numbers shown further up in the trace. But we will take these one at a time. How do you feel about noting the subshell level in one of the traceback stacks and allowing an optional parameter to set $LINENO in those cases where it is reset to 1. (Is there a corresponding variable for the filename? I note that in x=" $LINENO" LINENO has the x's line number rather than the one it's on. No doubt this is an artifact of xtrace wanting to show for tracing purposes x's line. However probably more correct would be to keep that but have $LINENO be the line that it itself is on. However assuming this is what's desired, attached is a test for the recent lineno-in-subshell change as well as a test for the LINENO in split assignment. Adjust that last test as desired. I've put these in a separate file and my test would be to move some of the other LINENO tests out of the overall variable test here, use again adjust (or discard) as desired. On Mon, Sep 29, 2008 at 4:52 AM, Peter Stephenson wrote: > On Sun, 28 Sep 2008 22:32:19 -0400 > "Rocky Bernstein" wrote: >> In general I think this will help. Not just because it helps the >> debugger. Later (* * * * below) I'll elaborate on this. >> >> But in short, either this patch doesn't solve this particular problem >> or I hand-applied the patch incorrectly. >>... >> When I run zsh with those patches on this program: >> ( >> x=$(print $LINENO); print $x >> ) >> >> I still get 1. Is that what one gets with the patch applied? > > No, you should get the line number in the file as I do, and you shouldn't > get any additional test failures. I don't think your version is working. > > I've now committed it, but with one additional change: parse_string() > still has the key additional reset_lineno logic, but it once again always > saves and restores the line number locally. That wouldn't make a > difference in this particular case but sometimes with the previous version > (I haven't bothered tracking down the exact places) you might get the > global line number being incremented too much. I don't think there's any > case where parsing the string should affect the line number from the > surrounding context. > >> Let me see if I understand the situation correctly: there is an >> internal routine called parse_string() which can be called though eval >> as well as backtick. For eval, one can argue its the right thing, but >> for backtick seeing 1 as the value of $LINENO might be a bit odd. > > Right. However, I've now tried to arrange it so that the line number is > only reset in places where zsh provides (through the function stack) enough > supporting for finding out what's actually going on. > > -- > Peter Stephenson Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ------=_Part_23648_18430414.1222686695028 Content-Type: application/octet-stream; name=V07lineno.ztst Content-Transfer-Encoding: base64 X-Attachment-Id: f_flp02i2l0 Content-Disposition: attachment; filename=V07lineno.ztst IyBUZXN0cyBvZiAkTElORU5PIHZhcmlhYmxlCiVwcmVwCgogbWtkaXIgbGluZW5vLnRtcCAKIGNk IGxpbmVuby50bXAKIHByaW50ICdhPTFcbmI9IlxuJExJTkVOTyI7IHByaW50IGFzc2lnbm1lbnQg bGluZW5vOiAkYlxuKFxuICAgYz0kKHByaW50ICRMSU5FTk8pOyBwcmludCBiYWNrdGljayBsaW5l bm86ICRjXG4pJyA+bGluZW5vLnNoCgogCiV0ZXN0CiAgJFpUU1RfdGVzdGRpci8uLi9TcmMvenNo IC4vbGluZW5vLnNoCjA6Q2hlY2tpbmcgc3BsaXQtbGluZSBhc3NpZ25tZW50IExJTkVOTyBhbmQg YmFja3RpY2sgc3Vic2hlbGwgTElORU5PCj5hc3NpZ25tZW50IGxpbmVubzogCj4yCj5iYWNrdGlj ayBsaW5lbm86IDUK ------=_Part_23648_18430414.1222686695028--