From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18160 invoked from network); 30 Aug 2008 14:49:37 -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 Aug 2008 14:49:37 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 65220 invoked from network); 30 Aug 2008 14:49:28 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 30 Aug 2008 14:49:28 -0000 Received: (qmail 2422 invoked by alias); 30 Aug 2008 14:49:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25560 Received: (qmail 2399 invoked from network); 30 Aug 2008 14:49:10 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 30 Aug 2008 14:49:10 -0000 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by bifrost.dotsrc.org (Postfix) with ESMTP id DB58880561C8 for ; Sat, 30 Aug 2008 16:49:05 +0200 (CEST) Received: by rv-out-0506.google.com with SMTP id g37so1082754rvb.21 for ; Sat, 30 Aug 2008 07:49:04 -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:mime-version:content-type:content-transfer-encoding :content-disposition; bh=l5ecVHeLO9YglVwB8u6flyVmzhaODO5JA9gwWfMaFdk=; b=pKMAm12meoiqyRYh6iHMgkFumTRBIvPg2PKr/nfuJXBu2lo0+awOR52wUYlmf8rZEn 9j0ZcR8u3I2eQOF5hRcc/Fs93BuNF+cYV0th4KMkYGUZElZ4FwfH2QpD6X9kAaRM0xVI kb+nbFjOKPjShP9qofbxEfIKlFFyMLTgbRZuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=cQAIVo72T/qX+itTNZxhz+fq5wYp8ATr9YunObcJEwNc/Xf7/yI7M9w63DWObqgiEP Nbgb8+vj7Q6pwa/W2stfcwZI09CjmivOmiluGqzGOkN60fuFOVcKx/JqJt2NZNylHBCd n12D4m7dnWG0TwkM6zIftOAyM5Lyq4N8GZYvg= Received: by 10.114.13.10 with SMTP id 10mr3724830wam.106.1220107743140; Sat, 30 Aug 2008 07:49:03 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Sat, 30 Aug 2008 07:49:03 -0700 (PDT) Message-ID: <6cd6de210808300749yf3cc8d4gadc62d8f7f96ec15@mail.gmail.com> Date: Sat, 30 Aug 2008 10:49:03 -0400 From: "Rocky Bernstein" To: "Zsh hackers list" Subject: line number reporting weirdnesses MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.92.1/8120/Sat Aug 30 05:43:49 2008 on bifrost X-Virus-Status: Clean Some of odd the behavior I've noticed in how line numbers gets set (as reported by funcfiletrace in trap DEBUG). Consider this program: #!/usr/local/bin/zsh -f debug_hook() { print '====' ; print $funcfiletrace[-1]; } set -o DEBUG_BEFORE_CMD trap "debug_hook" DEBUG if [[ "$TERM" != bogus ]]; then # line 5 [[ -z "$terminfo[kdch1]" ]] || bindkey -M emacs "$terminfo[kdch1]" delete-char [[ -z "$terminfo[khome]" ]] || bindkey -M emacs "$terminfo[khome]" beginning-of-line [[ -z "$terminfo[kend]" ]] || bindkey -M emacs "$terminfo[kend]" end-of-line fi x=' line 11 line 12 line 13' echo line 14 The output I get is: ==== ./linebug2.sh:5 ==== ./linebug2.sh:5 ==== ./linebug2.sh:3920 ==== ./linebug2.sh:3920 ==== ./linebug2.sh:3920 ==== ./linebug2.sh:13 ==== ./linebug2.sh:14 line 14 There are two effects I think shown above. First, the lines numbers of with [[ ]] inside if [[ ]] are weird - there is no line 3920. Second the line number in an assignment statement is basically the line of the string token which spans several lines. Possibly it might be more helpful to give the line number of the LHS token. What tends to happen say in a debugger is that someone will try to set a breakpoint on one of the line numbers that most people would associate with the weird line numbers (i.e. lines 6-8 or 10 above) and lacking a way to report which line numbers are possible stopping points as reported in funcfiletrace, people will get surprised when none of those lines don't get reported or stopped at. But of course the surprise is not limited to a debugger. Tools which track code coverage, or tools to time scripts or just a program where there is an error will also exhibit the weirdness. (Ruby has this interesting feature too. No doubt it's an artifact of LINENO getting set through a global variable tracking the the position of the character previously read.) - - - Recently added to zshdb was the ability to "next" or step over functions. It is possible way down the line stepping over functions may be slow because there is tracing overhead inside a function. If that's the case, more support in zsh might be warranted. Beforehand though it's probably premature optimization which Knuth says is the root of evil.