From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 262 invoked from network); 1 May 2000 17:20:51 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 May 2000 17:20:51 -0000 Received: (qmail 11605 invoked by alias); 1 May 2000 17:20:22 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 3053 Received: (qmail 11538 invoked from network); 1 May 2000 17:20:17 -0000 Date: Mon, 1 May 2000 13:13:28 -0400 From: Paul Ackersviller To: Bart Schaefer Cc: Zsh users list Subject: TRAPZERR() in chpwd() Message-ID: <20000501131328.A11940@tdc134.comm.mot.com> References: <20000428161546.A8208@tdc134.comm.mot.com> <1000429044220.ZM30544@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.11i In-Reply-To: <1000429044220.ZM30544@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Sat, Apr 29, 2000 at 04:42:20AM +0000 On Sat, Apr 29, 2000 at 04:42:20AM +0000, Bart Schaefer wrote: > On Apr 28, 4:15pm, Paul Ackersviller wrote: > } > } I guess it's intentional now that all tests which fail in chpwd() cause > } TRAPZERR() to be executed. > > Why do you guess that? It's certainly a surprise to me. Could you give > a more specific example of what you mean, though? TRAPZERR() is called > any time any command exits with a nonzero status, in chpwd or anywhere > else, and as far as I can tell it always has. Yes, I know all that; what I meant by `tests' was internal shell tests as opposed to external programs or other commands. Here's a simplified example of what I'm seeing. TRAPZERR () { echo exit code $?; } chpwd () { [ -h $PWD ] && echo symlink; true; } When I change to a directory that's not a soft link, I'm getting the `exit code' message from 3.1.7-pre-1, whereas I never have with earlier versions. I'm just wondering which way is correct, or are all versions correct and I'm just missing out on understanding something else that's related? > There is a bug in unsetting TRAPxxx (as opposed to resetting them to > something else) when localtraps is set. You might try `trap - ZERR' or > `disable -f TRAPZERR' instead for now. Thanks, `trap - ZERR' is really what I meant to do all along, i.e. affect only local behaviour inside the function, not global. -- Paul Ackersviller