history curiosities

history curiosities

[Peter Stephenson]

I'm getting rather confused with history.  The options I have set are given
at the end; I think what's really doing it is HISTIGNOREALLDUPS.  I have
HISTFILE, HISTSIZE and SAVEHIST set, though presumably the values aren't
that significant.

First, if I do `history' I get a listing without the last `history' in the
listing.  Yet when I do `!!', it's that `history' which is re-executed.
(Note I don't have histnostore set.)

I also have h as an alias for `history -fD'.  After
  echo one
  echo two
  echo three
  h
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.

Worse: I now set HISTNOSTORE in addition to the others, type `h', then
`!!'.  I get the message `no such event'.  After some more attempts with
those two commands, the whole thing goes haywire.  Repeating !! makes the
`h' listing show earlier and earlier parts of the list (seems to step back
4 every time).  After another command, typing `h' gives a `no such event'
message.  Sometimes the shell exits, but I haven't worked out how to
reproduce that.

I hope Wayne's out there somewhere...

noappendhistory       off
nobanghist            off
cshjunkiehistory      off
extendedhistory       on
histallowclobber      off
nohistbeep            off
histexpiredupsfirst   off
histfindnodups        off
histignorealldups     on
histignoredups        on
histignorespace       on
histnofunctions       off
histnostore           off
histreduceblanks      off
histsavenodups        off
histverify            on
incappendhistory      on
sharehistory          off

-- 
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

Re: history curiosities

[Bart Schaefer]

On Jul 16,  3:36pm, Peter Stephenson wrote:
} Subject: history curiosities
}
} I'm getting rather confused with history.  The options I have set are given
} at the end; I think what's really doing it is HISTIGNOREALLDUPS.  I have
} HISTFILE, HISTSIZE and SAVEHIST set, though presumably the values aren't
} that significant.
} 
} First, if I do `history' I get a listing without the last `history' in the
} listing.  Yet when I do `!!', it's that `history' which is re-executed.
} (Note I don't have histnostore set.)

This has always been the case.  Commands aren't entered into the history
until they finish being executed (or are stopped, or backgrounded with &).
That's one reason why the histnostore option exists.

} I also have h as an alias for `history -fD'.
[...]
} Worse: I now set HISTNOSTORE in addition to the others, type `h', then
} `!!'.  I get the message `no such event'.  After some more attempts with
} those two commands, the whole thing goes haywire.

This is new in pws-something: I can't reproduce it in 3.0.5 or 3.0.6-pre.

} I hope Wayne's out there somewhere...

Me, too.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: history curiosities

[Wayne Davison]

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.

> 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).

..wayne..

PATCH: Re: history curiosities

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

Re: PATCH: Re: history curiosities

[Peter Stephenson]

Peter Stephenson wrote:
> 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().

Looks like a false alarm, on closer examination.  freehistnode() does
indeed free the hist_ring that was around before, but freehistdata() has
already unlinked it from the ring and set hist_ring to something else as a
side effect.  So there's nothing wrong.

-- 
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