From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10423 invoked from network); 9 Aug 2004 15:10:01 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 9 Aug 2004 15:10:01 -0000 Received: (qmail 99938 invoked from network); 9 Aug 2004 15:09:54 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 9 Aug 2004 15:09:54 -0000 Received: (qmail 6154 invoked by alias); 9 Aug 2004 15:09:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20249 Received: (qmail 6141 invoked from network); 9 Aug 2004 15:09:40 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by 130.225.247.90 with SMTP; 9 Aug 2004 15:09:40 -0000 Received: (qmail 95835 invoked from network); 9 Aug 2004 15:07:42 -0000 Received: from acolyte.scowler.net (216.254.112.45) by a.mx.sunsite.dk with SMTP; 9 Aug 2004 15:07:40 -0000 Received: by acolyte.scowler.net (Postfix, from userid 1000) id AEFC97004E; Mon, 9 Aug 2004 11:07:37 -0400 (EDT) Date: Mon, 9 Aug 2004 11:07:37 -0400 From: Clint Adams To: Peter Stephenson Cc: zsh-workers@sunsite.dk, 183730-submitter@bugs.debian.org Subject: Re: Bug#183730: zsh: setting SAVEHIST breaks history saving without warning Message-ID: <20040809150737.GA10711@scowler.net> References: <20040808052133.GA11833@scowler.net> <200408090950.i799oaMM002904@news01.csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408090950.i799oaMM002904@news01.csr.com> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=-0.0 required=6.0 tests=BAYES_44 autolearn=no version=2.63 X-Spam-Hits: -0.0 > (Why does this `break history saving'? Or is the subject line > inaccurate? I'll assume the latter for now.) I think he set SAVEHIST to some enormously large value which wrapped to 0, and thus the saving of his history was "broken", without a clear indication why. > The number assigned is obviously too large to be directly useful; what > was the intention? Always save values at the end of the history list > regardless of what was there already? Perhaps. Tollef, could you elaborate?