PATCH: Re: history curiosities

[Peter Stephenson <pws@ibmth.df.unipi.it>]

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 <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy