From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29300 invoked from network); 18 Jul 1999 15:30:36 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jul 1999 15:30:36 -0000 Received: (qmail 19749 invoked by alias); 18 Jul 1999 15:30:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7184 Received: (qmail 19742 invoked from network); 18 Jul 1999 15:30:24 -0000 Message-Id: <9907181459.AA12423@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: PATCH: Re: history curiosities In-Reply-To: "Wayne Davison"'s message of "Sat, 17 Jul 1999 17:03:09 DFT." Date: Sun, 18 Jul 1999 16:59:28 +0200 From: Peter Stephenson Wayne Davison wrote: > On Fri, 16 Jul 1999, Peter Stephenson wrote: > > I get what I said above; the h is not listed. Now when I do > > `history', the `h' is listed but the `history' isn't, i.e. the > > last two entries shown are `echo three' and `h'. Now if I do `h' > > again, the `h' disappears and `history' shows up. > > Yeah, that's all behaving like it should -- history doesn't show > the command you typed to show the history, and since you have the > HIST_IGNORE_ALL_DUPS option set, when you re-enter 'h', the older > 'h' command vanishes. Hmm, it's strange that aliases are treated as expanded when they don't show up that way. I don't particularly like it, but I can live with it. > > Worse: I now set HISTNOSTORE in addition to the others, type `h', > > then `!!'. I get the message `no such event'. > > I am unable to duplicate this using an almost stock 3.1.6-pre-1 > (the only patches I have applied are the ones I'm about to email > to the list). The problems show up with a complex precmd() --- in fact, only certain things in precmd() seem to tickle it. However, the underlying problems are easy to see once you find out what's happening. They both revolve around remhist(), specifically the code when history is not active. This does two things: adds the flag HA_JUNKED to histactive, and frees hist_ring. Both cause problems. The first one is probably not new. When something gets executed non-interactively from precmd (or anywhere else, come to that), lexsave() saves histactive, but doesn't reset it --- so HA_JUNKED is still set, and curhist gets decreased immediately, then again every time histactive is restored to its original value by lexrestore(). This can probably be handled by setting histactive to 0 in lexsave. This is in the attached patch --- it seems to fix the problems I was seeing and I can't see how it can be (very) wrong. The second is presumably new, and is a bit harder; I only discovered it because of the first one. In remhist(), the hist_ring is freed under the circumstances I'm talking about (a history command with HISTNOSTORE), but is not set to NULL, so is referred to again with the next hbegin(). Unfortunately, naive fixes --- setting it to NULL, or delaying freeing and setting it to NULL until the point where HA_JUNKED is handled in hbegin() --- don't work, because the history number code needs this entry to work out default history numbers for `history', etc. It may be easy enough, just do the the usually stuff for HISTIGNOREDUPS or whatever, only at the point HA_JUNKED is checked, but I've left this for Wayne to do properly. I haven't seen any effects of this bug, but it's clearly not right. --- Src/lex.c.hist Sun Jul 18 16:14:32 1999 +++ Src/lex.c Sun Jul 18 16:44:52 1999 @@ -241,6 +241,7 @@ cmdsp = 0; inredir = 0; hdocs = NULL; + histactive = 0; ls->next = lstack; lstack = ls; -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy