From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23768 invoked from network); 18 May 2004 11:29:48 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 18 May 2004 11:29:48 -0000 Received: (qmail 29523 invoked from network); 18 May 2004 11:29:23 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 May 2004 11:29:23 -0000 Received: (qmail 26730 invoked by alias); 18 May 2004 11:29:21 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19953 Received: (qmail 26720 invoked from network); 18 May 2004 11:29:20 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 18 May 2004 11:29:17 -0000 Received: (qmail 29348 invoked from network); 18 May 2004 11:29:16 -0000 Received: from lhuumrelay3.lnd.ops.eu.uu.net (62.189.58.19) by a.mx.sunsite.dk with SMTP; 18 May 2004 11:29:15 -0000 Received: from MAILSWEEPER01.csr.com (mailhost1.csr.com [62.189.183.235]) by lhuumrelay3.lnd.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id i4IBSkv28750 for ; Tue, 18 May 2004 11:28:47 GMT Received: from EXCHANGE02.csr.com (unverified [192.168.137.45]) by MAILSWEEPER01.csr.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Tue, 18 May 2004 12:28:15 +0100 Received: from csr.com ([192.168.144.127]) by EXCHANGE02.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 May 2004 12:30:39 +0100 To: zsh-workers@sunsite.dk Subject: Re: zcalc bug In-reply-to: "Wayne Davison"'s message of "Fri, 14 May 2004 17:22:17 PDT." <20040515002217.GE22331@blorf.net> Date: Tue, 18 May 2004 12:28:46 +0100 Message-ID: <8428.1084879726@csr.com> From: Peter Stephenson X-OriginalArrivalTime: 18 May 2004 11:30:39.0669 (UTC) FILETIME=[8BEB2E50:01C43CCB] X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: * X-Spam-Status: No, hits=1.6 required=6.0 tests=BAYES_60 autolearn=no version=2.63 X-Spam-Hits: 1.6 Wayne Davison wrote: > OK, I created an initial implementation of this today (it was pretty > easy, as I expected). See if you like it. It works in my limited > testing (i.e. a modified zcalc works quite nicely), but I may have > missed something. Thanks. Just got a chance to try this. Seems fine, so far. > > Do you think it's easy to keep the state of external files consistent > > while you do that? > > I'm not sure what you mean by this. My code isn't doing anything with > files, so the modified zcalc function still loads the .zcalc_history > file with "fc -R" and its restore function writes it out with "fc -W". > However, no fc calls are needed to save and restore the current history. Well, it does seem to get the history numbers right when reading the file back. > It would be possible to change my current, very simple pushhist/pophist > syntax to have pushhist optionally take some parameters to setup the new > history environment, for instance: > > pushhist 200 100 ~/.zcalc_history > > would be just like this shell code: > > pushhist > HISTSIZE=200 > SAVEHIST=100 > HISTFILE=~/.zcalc_history > [[ -f $HISTFILE ]] && fc -R > > And the pophist function could likewise be changed to work like this: > > [[ ! -z $HISTFILE && $SAVEHIST > 0 ]] && fc -W > pophist You're proposing that you would *only* need the pushhist and pophist functions to manipulate the history? That sounds a good thing to me. Something else that occurs to me is that it would be useful to have the history automatically popped when you leave the function scope. That saves a lot of messing on with traps, which will never be completely safe. However, there may be uses where you want to stay in an alternative history between functions, though I can't think of any off the top of my head, so I don't know if that's the right thing to do in general. It would certainly make zcalc simpler and more reliable. (There are various mechanisms associated with function scoping, without looking I'm not sure which would be the best here.) I'm not sure a separate command is necessary; it could be a new option to history (or both history and fc). We could get essentially all the above with: history -p 200 100 ~/.zcalc_history push the history as you suggested history -P pop the history, saving the temporary $HISTFILE first and restoring the original one history -Lp 200 100 ~/.zcalc_history push the history for the current local scope, restoring it automatically when the function exits. I could be persuaded to the view that the local behaviour is the right one, so you never need an explicit pop, and the syntax becomes even simpler. That significantly reduces the likelihood of people getting their history screwed up. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************