From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16376 invoked from network); 11 Oct 2001 16:31:39 -0000 Received: from unknown (HELO sunsite.dk) (130.225.247.90) by ns1.primenet.com.au with SMTP; 11 Oct 2001 16:31:39 -0000 Received: (qmail 18911 invoked by alias); 11 Oct 2001 16:31:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16012 Received: (qmail 18894 invoked from network); 11 Oct 2001 16:31:18 -0000 From: Bart Schaefer Message-Id: <1011011163054.ZM18442@candle.brasslantern.com> Date: Thu, 11 Oct 2001 16:30:54 +0000 In-Reply-To: Comments: In reply to martin.ebourne@arcordia.com "Very odd behaviour with zsh, maybe corruption bug" (Oct 11, 11:57am) References: X-Mailer: Z-Mail (5.0.0 30July97) To: martin.ebourne@arcordia.com, zsh-workers@sunsite.dk Subject: Re: Very odd behaviour with zsh, maybe corruption bug MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 11, 11:57am, martin.ebourne@arcordia.com wrote: } } SunOS gdd-odybin2 5.6 Generic_105181-28 sun4u sparc } SUNW,Ultra-Enterprise-10000 } } gdd-odybin2% +_down_fn:3> [[ new-up == new-up ]] } +_down_fn:8> [[ "abc } def" == * } * ]] } +_down_fn:10> _searching= } +_down_fn:11> zle .down-line-or-history I can't reproduce this on my linux machine, even after ten minutes or so of fooling with it. For [[ ]], the trace output is generated before the right-hand-side is copied and compiled into a pattern for comparison to the left-hand-side, so it could be the case that memory errors result in a bad comparison; but they'd be far more likely to produce a "bad pattern" error instead. This is a long, long, long shot, but: You don't happen to be using a debug trap? (I.e., a TRAPDEBUG function, or `trap ... DEBUG') Have you tried configuring with --enable-zsh-debug ? -- 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