From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22224 invoked by alias); 27 Jun 2015 19:34:37 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20283 Received: (qmail 15509 invoked from network); 27 Jun 2015 19:34:36 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=TTvaiUrXR5RVs4ouLqcx7aD7cfQP6k96k7MjGLuSoRc=; b=Hnum2+WWOCl62o05ZFy8DP0MQlWS9sk+syzwnsIULSkhgDI+21MfJQONcOFAqW9iw7 4YeUDkjkb5W5Ya9MYWnMmDUFiH+j+yXYX/x0nxW/Uqb3G6YtSyv6V5YDth1UECA1kjG/ OP1KtTxoabnlPsIMa6S7Mjh4s4aFoZ0nLMym5uQG9F21IH258f964hK4UNm5SmKaZCLe OOqSa2PjuKdWPadNrrRCcpnhtdUvqCGexyt29dBR0u0Wh1YhCP3lgqmGD78uEzk1MO+B rs6acsm9OCtTqtRgtQbEUsiGlCW5/aiBaMqzqK+t2eO3n3zkZ+zJ7yrGd71ntuUeQcbU KSCQ== X-Gm-Message-State: ALoCoQnWhR8LkHVXSdJD8ln5PvSEqyMkaixwwNYYhc1VliHHD4jy55UMoXhKlpBB3zPRz1YdXVR9 X-Received: by 10.202.106.147 with SMTP id f141mr6632334oic.65.1435433674841; Sat, 27 Jun 2015 12:34:34 -0700 (PDT) From: Bart Schaefer Message-Id: <150627123426.ZM3772@torch.brasslantern.com> Date: Sat, 27 Jun 2015 12:34:26 -0700 In-Reply-To: <150627113525.ZM3645@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: Tab completion error after upgrade" (Jun 27, 11:35am) References: <150626145238.ZM21872@torch.brasslantern.com> <20150627174341.6cbc20de@ntlworld.com> <150627113525.ZM3645@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Assorted TRAPxxx / trap xxx observations MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 27, 11:35am, Bart Schaefer wrote: } } ... they deliberately DID use the trap builtin when I added them, but } it was determined that some side-effects didn't propagate correctly if } functions were not used. Incidentally, anonymous functions provide (inflict?) some interesting semantics for the "trap" command. torch% unsetopt debug_before_cmd torch% trap '() { print $LINENO $1 } $LINENO' DEBUG 0 2 torch% echo "What's my line?" What's my line? 0 3 torch% A couple of fun things there. 1. This is probably obvious, but it means you can get the benefits of a separate function context in the trap without side-effect of the return value acting as an interrupt. Are there other non-obvious things? Any of this worth adding to the doc? 2. Installing a DEBUG trap with NODEBUG_BEFORE_CMD in effect causes the setting of the trap to debug itself. Regarding the return value acting as an interrupt, a nonzero return from a DEBUG_BEFORE_CMD trap behaves exactly the same as "setopt ERR_EXIT" in that it prevents the upcoming command from executing. Either this is an unintentional change, or we don't need the ERR_EXIT trick any more. I also previously had not considered the interaction of $? with debug traps, specifically DEBUG_BEFORE_CMD. (Sorry, Peter, I'm about to make your eyes glaze over, again.) The upshot is that $? in the trap refers to the previous command in one case, and to the command being debugged in the second case. torch% trap '() { print ERR $? }' ZERR torch% trap '() { print DBG $? }' DEBUG torch% false DBG 0 ERR 1 torch% true DBG 1 torch% unsetopt debugbeforecmd DBG 0 torch% false DBG 1 ERR 1 torch% true DBG 0 torch% I suppose $? has to be the status of the previous command in the debug trap when it runs before, because the upcoming command has to be able to test the previous command's status. Mostly this raises documentation issues. It's not mentioned anywhere that toggling DEBUG_BEFORE_CMD inside the trap will NOT cause the trap to execute twice (something that might be interesting if you want to examine $? both before and after). It's also not explicitly called out that the value of $? always refers to whatever executed right before the trap, which differs with the state of DEBUG_BEFORE_CMD, but this may be considered obvious. That's all for now ... -- Barton E. Schaefer