From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25924 invoked from network); 6 Aug 2008 21:19:46 -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=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; 6 Aug 2008 21:19:46 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 72643 invoked from network); 6 Aug 2008 21:19:33 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 Aug 2008 21:19:33 -0000 Received: (qmail 4292 invoked by alias); 6 Aug 2008 21:19:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25411 Received: (qmail 4267 invoked from network); 6 Aug 2008 21:19:20 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 Aug 2008 21:19:20 -0000 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by bifrost.dotsrc.org (Postfix) with ESMTP id D46FA805A433 for ; Wed, 6 Aug 2008 23:19:15 +0200 (CEST) Received: by py-out-1112.google.com with SMTP id u77so74441pyb.23 for ; Wed, 06 Aug 2008 14:19:15 -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=8yVKFS0Uj+pPWOpOD03PbdkzdUZscIdEfsQw3zzI80A=; b=RKN3LSV8iB3e0XKdIhhIeK+NpRjkPzJqGyNvQwGMhTcKeJXobJQU+8xn5+7KlrcN48 2yz9E0Z/HsVp/NhGTBK9jCUZg/CIGimDqQ4on/Kpvwgb442ajsb2BPQAvj4LOK87lfAC sXmU1MROH7LRo1eUFThMBfIA1eCGyWyJBK6eg= 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=BrRoERKQXpNYznPKYk4BqERzWFGEL4EACoui/y/HEZl1Doc09zZoLlVuYPphxERNrE Qe24FJbY8I6jbpOAsk1MAZ6b5JI/CKZJBgHbp3TsstiCTKr8rJxA4OuGZgelnHxc81L9 /7cf9wciT76Ul7Ib8quWxi4KxY5/3Va3L7R9o= Received: by 10.114.205.1 with SMTP id c1mr955972wag.56.1218057554734; Wed, 06 Aug 2008 14:19:14 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Wed, 6 Aug 2008 14:19:14 -0700 (PDT) Message-ID: <6cd6de210808061419q2a81856cv62969490069e8f3e@mail.gmail.com> Date: Wed, 6 Aug 2008 17:19:14 -0400 From: "Rocky Bernstein" To: "Zsh hackers list" Subject: DEBUG_CMD_LINE (Was Re: PATCH: skip command from debug trap) 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/7961/Wed Aug 6 22:29:59 2008 on bifrost X-Virus-Status: Clean On Wed, Aug 6, 2008 at 3:49 PM, Peter Stephenson wrote: > "Rocky Bernstein" wrote: >> But given the choice of adding >> 1) an option in the return statement everywhere that is specific to >> just "trap DEBUG" or >> 2) specifying what specific numbers do when on a return from "trap DEBUG", >> >> isn't 2) simpler and more consistent with programming in shell >> languages work? I take it as a given that every function or command is >> going to have error codes that are somewhat arbitrary and that I'm not >> going to intuit. > > I'm in two minds about this. Ok. I'm sure you'll do what's best and let us know what is decided. > If we didn't have the existing rule that > any non-zero return status from TRAPDEBUG, or any explicit return from > within an inline trap, forced an immediate return, then I'd agree simply > adding to the set of useful statuses was cleaner and more natural. As > it is, we're now forced to pick some numeric value the user wouldn't > naturally want to return from am enclosing context (since the return > value is propagated). > > The option to return seems to me natural enough, because as "return" > means "just return", so "return with an option" means "return but with > slightly different semantics". Having a different return status meaning > to execute different code (rather than simply provide a different test > for the caller, as normal) is an unusual enough effect that it doesn't > strike me as the unequivocal answer. > > But, whatever. If there's a number we all really like to mean "skip", > we can go with that. It's already working, is easy to document, and > doesn't need any changes to parsing. > > (By the way, it wouldn't be too hard, if not completely trivial, to pass > down the code about to be executed in a variable, say DEBUG_CMD_LINE, as > reconstructed text, i.e. the same sort of format as what you get if you > get the shell to output a shell function that's already loaded. But > it's messy enough that I won't unless it's definitely useful.) My secret plan was to get the debugger working enough for folks to realize this would be useful. In bash the variable $BASH_COMMAND holds the command that is up for execution next. It is not the "line" (as suggested in the name DEBUG_CMD_LINE) but the last command or statement. And although DEBUG_CMD_LINE can be used in debugging, there's nothing about it that strictly needs to be so. For example suppose I wanted to get statistics on how many commands are run that start with the letter A. Anyway, in debugging where it's most useful are places where there are statement lines for example [[ -z $FOO ]] && bar || baz temp=x; x=y; y=temp If one is is stepping along it can be useful to know in which part of the line you are about to run. The hueristic that bashdb uses is that if the line number is the same as the last line number that it stopped at but the command string changes, then it's probably a good idea to show not just the line but also the command that is about to be executed. In practice this means that one can assume that whenever you see a line with more than one statement and no statement is explicitly printed, then one can assume that the statement that is about to be run is the first one shown. And if one is not sure one can just run a print $BASH_COMMAND debugger command. > > -- > Peter Stephenson > Web page now at http://homepage.ntlworld.com/p.w.stephenson/ >