From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29839 invoked from network); 9 Jul 2001 16:52:04 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Jul 2001 16:52:04 -0000 Received: (qmail 27991 invoked by alias); 9 Jul 2001 16:51:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15330 Received: (qmail 27939 invoked from network); 9 Jul 2001 16:51:52 -0000 From: "Bart Schaefer" Message-Id: <1010709165031.ZM20928@candle.brasslantern.com> Date: Mon, 9 Jul 2001 16:50:31 +0000 In-Reply-To: Comments: In reply to Peter Stephenson "Re: Debugging of dynamocally defined functions" (Jul 9, 3:52pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: Debugging of dynamocally defined functions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 9, 3:52pm, Peter Stephenson wrote: } Subject: Re: Debugging of dynamocally defined functions } } I've discovered that bash simply gives 0 for line numbers in eval. This } (perl-like) behaviour of numbering eval's separately is probably more } useful than that, at least. } } I suspect the only way of finding out whether people prefer this behaviour } is to commit it. So I'll do that and produced 4.1.0-dev-1. After playing with this for a few minutes I have the following observations: In xtrace output the `eval' itself gets a line number before the commands that it executes are numbered, so that's fine -- it's possible to track the eval to a line in the calling function/file. However, neither the value of %N nor that of %_ in PS4 changes to indicate that you've entered a new line numbering scope; only %i changes. For a large `eval' that can be quite distracting. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net