From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9398 invoked from network); 29 Sep 2008 14:12:30 -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; 29 Sep 2008 14:12:30 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 59726 invoked from network); 29 Sep 2008 14:12:20 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 29 Sep 2008 14:12:20 -0000 Received: (qmail 9502 invoked by alias); 29 Sep 2008 14:12:12 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25769 Received: (qmail 9484 invoked from network); 29 Sep 2008 14:12:11 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 29 Sep 2008 14:12:11 -0000 Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by bifrost.dotsrc.org (Postfix) with ESMTP id 5958580309AA for ; Mon, 29 Sep 2008 16:11:59 +0200 (CEST) Received: by wf-out-1314.google.com with SMTP id 29so2371105wff.3 for ; Mon, 29 Sep 2008 07:11:57 -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=lOwBZWcRo2cQuwqKvKjOlLDWtTLDCnV4Xdqwbf+lTbM=; b=fwUtcFY7c2YdqeRjw387NV4zLsemxqS4sbZSDaVVNg7eu3HBoVTPAN409LIKY2f7qZ yUfOk6pVnPH3On6jv69cK1wlMTUs/7BVjr57CrGGllmXhmWiHXDU0NcxmSRqNnQQIQd2 ubq7Qkr+KW7MYwtHo4e4QkoB0JhrEOtH63C2s= 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=rRrR3KQWqGSzQ9kQ1bWHJChKiWDbfWg9E44Kkam/fdFEpq+VRTTE1Y/NEHf2bj+n9c tHJrl+oKgti2mgyCzRe+AjTqCMPljow7xfC9WLBcJSHnKmW15OK8sW9QNw7pDLF4HXXz 5w45LzYNpxDBJEYVo6Cq7ozx8/v3N1yHDys2I= Received: by 10.114.144.1 with SMTP id r1mr5764029wad.136.1222697517572; Mon, 29 Sep 2008 07:11:57 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Mon, 29 Sep 2008 07:11:57 -0700 (PDT) Message-ID: <6cd6de210809290711j12363e1bo159e1739bae7b2fd@mail.gmail.com> Date: Mon, 29 Sep 2008 10:11:57 -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: <200809291125.m8TBPsQM005256@news01.csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6cd6de210809281219i4bf1ed18mefa45b967fa835a6@mail.gmail.com> <20080928221651.6ee7f671@pws-pc> <6cd6de210809281932u2e04a844l219d1db5a7568a73@mail.gmail.com> <20080929095201.451381d0@news01> <6cd6de210809290411m60cb669bk3817d768adce378a@mail.gmail.com> <200809291125.m8TBPsQM005256@news01.csr.com> X-Virus-Scanned: ClamAV 0.92.1/8353/Mon Sep 29 11:57:09 2008 on bifrost X-Virus-Status: Clean On Mon, Sep 29, 2008 at 7:25 AM, Peter Stephenson wrote: > "Rocky Bernstein" wrote: >> 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. > > Please could you send a simple example of a remaining incorrect line > number. I would expect it would be reproducible without the debugger. Sorry. Here's a trace from the reduced debugger. I've added comments as before. ./zshdb2.sh ./zshdb2.sh:39 ./zshdb2.sh:34 # Debug output in lib/frame.sh # Above should be: ./lib/hook.sh:5 ./zshdb2.sh:34 # note: 34+5=39 (./zshdb2.sh:34): # Comes from debugger via above save . ./testing.sh ./zshdb2.sh:39 ./zshdb2.sh:34 # lib/frame.sh output again zshdb<1> p ${funcfiletrace[@]} ./command/eval.sh:38 ./command/eval.sh:56 ./lib/processor.sh:100 ./lib/processor.sh:49 ./zshdb2.sh:39 ./zshdb2.sh:34 # Above should be: ./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96 ./lib/processor.sh:44 ./lib/hook:13 ./lib/hook.sh:6 ./zshdb2.sh:39 ./zshdb2.sh:34 Note that the difference in the two ./lib/processor.sh call lines is 52 in one case and 51 in another. It gets even screwier after this, Just install that reduced debugger and keep stepping and printing funcfiletrace. But again, perhaps it is best to take things one step 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. > > I'm not entirely sure what you're referring to, please could you give an > example of what behaviour you'd like. Ok. But I'm responding to your assertion that in some cases the line number is reset to 1 in places where you can figure that out via funcfiletrace. I see that eval doesn't seem to be such a case. Suppose eval line numbers were reset but it is shown as a call in the stack traces as it is in Python and Ruby. This code then # This is line 5 eval "x=1; y=$LINENO" would set y to 2 since that's the second line in the eval. Since eval is a POSIX "special" builtin, let's say there is an eval2 which allows optional file and line number parameters eval "x=1; y=$LINENO" 10 foo.c Then y would be set to 10. And *stack* routines where we can see filename, it would be "foo.c" > >> (Is there a corresponding variable for the filename? > > LINENO itself doesn't necessarily relate to a file, but for now you can > use ${(%):-%x} and ${(%):-%I} for the filename and line number in the > shell code which is probably what you need. I'll add variables for > these later if they turn out to be useful (probably ZSH_SOURCE_FILE and > ZSH_SOURCE_LINE). Ok - Thanks. Will see how this works out. I'm not a fan of only having % notation which looks like line noise and as you yourself had said in the past %x is a bit non-intuitive. > >> 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. > > I think we'd have to track the line number in subst.c:stringsubst(). > That may or may not be simple, I'll have to try it. I think it will help. Thanks.