From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5434 invoked from network); 13 May 2004 20:06:25 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 13 May 2004 20:06:25 -0000 Received: (qmail 19439 invoked from network); 13 May 2004 20:05:40 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 May 2004 20:05:40 -0000 Received: (qmail 10442 invoked by alias); 13 May 2004 20:05:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19942 Received: (qmail 10429 invoked from network); 13 May 2004 20:05:32 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 13 May 2004 20:05:28 -0000 Received: (qmail 16885 invoked from network); 13 May 2004 20:04:04 -0000 Received: from dsl3-63-249-88-2.cruzio.com (HELO binome.blorf.net) (63.249.88.2) by a.mx.sunsite.dk with SMTP; 13 May 2004 20:04:02 -0000 Received: by binome.blorf.net (Postfix, from userid 1000) id F13E2256A; Thu, 13 May 2004 13:03:59 -0700 (PDT) Date: Thu, 13 May 2004 13:03:59 -0700 From: Wayne Davison To: Peter Stephenson Cc: zsh-workers@sunsite.dk Subject: Re: zcalc bug Message-ID: <20040513200359.GA8171@blorf.net> References: <20040513140450.GA27267@picard.franken.de> <20277.1084460278@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20277.1084460278@csr.com> User-Agent: Mutt/1.5.5.1+cvs20040105i 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=none autolearn=no version=2.63 X-Spam-Hits: 0.0 On Thu, May 13, 2004 at 03:57:58PM +0100, Peter Stephenson wrote: > Wayne, have you any idea how easy it would be to implement something > to make switching history files easy? I'd like to see something that doesn't involve saving and restoring the lines of the current history to a file, but instead just shunts aside the internal data temporarily. This would be the least disruptive, especially since some info is lost when it gets written out and re-read (I'm thinking of the local/imported distinction when sharing history between multiple shells as at least one such thing that is lost). A couple different potential idioms for surfacing this to the user come to mind: pushhist; ...; pophist setopt localoptions tmphist Both would do approximately the same thing internally, but I would assume that a push/pop idiom would be expected to handle more than one saved history at a time. Either one would save and restore the history- related environment variables (like HISTFILE & HISTSIZE) but (I assume) not any of the history-related options (those a script could set locally using the already-existing means). It doesn't seem like it would be too hard to find all the variables that need to be tweaked (maybe putting them into a single structure) and then implementing something that can save and restore them under user control. What do you think? ..wayne..