[4.0.2 bug] commands not written to history

[4.0.2 bug] commands not written to history

[Vincent Lefevre]

I sometimes write related commands like

$ cmd1
$ cmd2

And several hours/days later, I can recall cmd1 from the history and
type ^O to recall cmd2 automatically. I don't want to do that in a
script or in a function, to have full control on these commands (and
be able to insert commands between cmd1 and cmd2 if need be).

But sometimes (difficult to say under which conditions), a copy of cmd1
had been written to the history (as expected), but there is no copy of
cmd2. That is, ^O gives me another command (instead of cmd2).

Here are my history options:

greux:~> setopt|grep hist                                             <16:29:44
extendedhistory
histignoredups
histignorespace
histnofunctions
histnostore
histreduceblanks
incappendhistory
greux:~> unsetopt|grep hist                                           <16:29:46
noappendhistory
nobanghist
cshjunkiehistory
histallowclobber
nohistbeep
histexpiredupsfirst
histfindnodups
histignorealldups
histsavenodups
histverify
sharehistory

I reported a similar problem for zsh 3.1.9 in November (message-id of
the first mail: <20001129141451.A24159@lepois.loria.fr>). And I got a
reply saying:

--------
IIRC, this bug was fixed back in July:

2000-07-17  Wayne Davison  <wayned@users.sourceforge.net>

        * 12265: Src/hist.c: Fixed gethistent().

In the case you cite, the gethistent() function would sometimes fail when
called from savehistfile().
--------

I don't know if this is related...

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Bart Schaefer]

On Jun 29,  4:33pm, Vincent Lefevre wrote:
} Subject: [4.0.2 bug] commands not written to history
}
} I sometimes write related commands like
} 
} $ cmd1
} $ cmd2
} 
} (and be able to insert commands between cmd1 and cmd2 if need be).
} 
} But sometimes (difficult to say under which conditions), a copy of cmd1
} had been written to the history (as expected), but there is no copy of
} cmd2. That is, ^O gives me another command (instead of cmd2).

And you're quite sure that you never *did* need to insert commands in
between cmd1 and cmd2, at some point in past history?

} Here are my history options:
} 
} incappendhistory
  ^^^^^^^^^^^^^^^^

Are you also sure that you've never had two shells running at the same
time, such that their incremental appends to the history might become
interleaved?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

On 29 Jun, Bart Schaefer <schaefer@candle.brasslantern.com> wrote:
> And you're quite sure that you never *did* need to insert commands in
> between cmd1 and cmd2, at some point in past history?

Yes. I can even tell you that the last time this problem occurs, the
command after cmd1 was xinit, i.e. the first command I type after I
log in.

> } Here are my history options:
> } 
> } incappendhistory
>   ^^^^^^^^^^^^^^^^

> Are you also sure that you've never had two shells running at the same
> time, such that their incremental appends to the history might become
> interleaved?

I probably had several opened shells. But here, I'm sure I typed both
commands one after the other. And anyway, a xinit can't have been
interleaved. It seems that cmd2 simply disappeared from the history;
cmd2 probably was the last command I typed in the shell, then I logged
out, and logged in again (thus, the xinit in the history just after
cmd1).

BTW, I use NFS, but all the shells were on the same machine.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Bart Schaefer]

On Jun 29,  8:14pm, Vincent Lefevre wrote:
} Subject: Re: [4.0.2 bug] commands not written to history
}
} I can even tell you that the last time this problem occurs, the
} command after cmd1 was xinit, i.e. the first command I type after I
} log in.
} 
} I probably had several opened shells. But here, I'm sure I typed both
} commands one after the other. And anyway, a xinit can't have been
} interleaved.

This being the case, you can check what happened to xinit by examining
the history file from a new shell as soon as you have X up and running.
With incappendhistory, `xinit' should already be the last command in
the file before `xinit' itself runs -- so assuming that your shells in
xterm (or whatever emulator) are using the same history file as your
console shell, typing <C-p> as soon as a new terminal opens should show
you `xinit', and <C-p> again should show you `cmd1'.  If history files
aren't the same, `tail' the one the console should have written.

An important thing to note is that with incappendhistory set, zsh will
not re-write the history file again at shell exit.  If you did anything
at all in a shell from within X, and then you immediately `exit' from the
console after the X server shuts down, the last commands in the history
will be those saved by the shells within X.

} BTW, I use NFS, but all the shells were on the same machine.

NFS could be a factor even if only one client machine is involved.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

On Sat, Jun 30, 2001 at 16:06:14 +0000, Bart Schaefer wrote:
> } BTW, I use NFS, but all the shells were on the same machine.
> 
> NFS could be a factor even if only one client machine is involved.

Having had several problems(*) due to NFS (with 1 client), this could
be the case... Is there a way to lock the history file when something
is written to it?

(*) rm -r sometimes returns a strange error, emacs can't be compiled.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

On Sat, Jun 30, 2001 at 16:06:14 +0000, Bart Schaefer wrote:

[my problems about commands disappearing from the history, under Linux]
> NFS could be a factor even if only one client machine is involved.

Since the problem occurred twice today, I decided to store the history
to the local hard disk. So, I'll see if the problem still occurs or not.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

On Thu, Jul 12, 2001 at 00:34:59 +0200, Vincent Lefevre wrote:
> Since the problem occurred twice today, I decided to store the history
> to the local hard disk. So, I'll see if the problem still occurs or not.

There is another problem. For instance, when I want to backward-search
for `file.', nothing is found, though there is a matching line in the
history:

greux:~out> grep "zip -r" $HISTFILE                                    <1:48:28
: 994891028:0;zip -r file.zip *
: 994895233:0;grep "zip -r" $HISTFILE
greux:~out> grep "zip -r" $HISTFILE                                    <1:48:29
failing bck-i-search: file._

It seems to be due to the fact that the time stamps are not in the
increasing order.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Bart Schaefer]

On Jul 12,  1:59am, Vincent Lefevre wrote:
} Subject: Re: [4.0.2 bug] commands not written to history
}
} There is another problem. For instance, when I want to backward-search
} for `file.', nothing is found, though there is a matching line in the
} history:
} 
} greux:~out> grep "zip -r" $HISTFILE                                    <1:48:28
} : 994891028:0;zip -r file.zip *
} : 994895233:0;grep "zip -r" $HISTFILE
} greux:~out> grep "zip -r" $HISTFILE                                    <1:48:29
} failing bck-i-search: file._

Hrm.  Just because there's an entry in $HISTFILE doesn't mean that it's
present in the shell history, of course.  With INC_APPEND_HISTORY set
(as I believe you have), $HISTFILE may have up to $[SAVEHIST/5] extra
commands stored in it.  (This is to avoid having to rewrite the entire
file too frequently.)  But only $HISTSIZE of those commands is actually
in memory (and thus searchable) at any given time.

Next time you see this happen, try running `fc -W temphistfile' and then
`diff $HISTFILE temphistfile'.  You should see differences only at the
beginning and possibly one or two commands at the end, not in the middle.
If there are commands missing (or misordered) in the middle, then we'll
have evidence of a real bug.
 
} It seems to be due to the fact that the time stamps are not in the
} increasing order.

Can you show an example of this, please?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

On 12 Jul, Bart Schaefer <schaefer@candle.brasslantern.com> wrote:

> Hrm.  Just because there's an entry in $HISTFILE doesn't mean that it's
> present in the shell history, of course.  With INC_APPEND_HISTORY set
> (as I believe you have), $HISTFILE may have up to $[SAVEHIST/5] extra
> commands stored in it.  (This is to avoid having to rewrite the entire
> file too frequently.)  But only $HISTSIZE of those commands is actually
> in memory (and thus searchable) at any given time.

But this wasn't the problem, as the history contained about 100 lines
(it was just after I used a new history file), and $HISTSIZE is 2000
here.

> Next time you see this happen, try running `fc -W temphistfile' and then
> `diff $HISTFILE temphistfile'.  You should see differences only at the
> beginning and possibly one or two commands at the end, not in the middle.
> If there are commands missing (or misordered) in the middle, then we'll
> have evidence of a real bug.

greux:~[Failed 130]> fc -W temphistfile                               <14:30:51
greux:~> diff $HISTFILE temphistfile                                  <14:35:11
112c112
< : 994936533:0;mail
---
> : 994937129:867;mail
116,120c116,119
< : 994939941:0;m $HISTFILE
< : 994939999:0;mail
< : 994940004:0;m $HISTFILE
< : 994940081:0;mail
< : 994940743:0;rem
---
> : 994939966:13;m $HISTFILE
> : 994939999:2;mail
> : 994940004:8;m $HISTFILE
> : 994940743:308;rem
122d120
< : 994941319:0;diff $HISTFILE temphistfile

Is it normal?

It seems that a "mail" command has disappeared from the history file.

> } It seems to be due to the fact that the time stamps are not in the
> } increasing order.

> Can you show an example of this, please?

This can be done by manually copying commands to the history file
(useful when starting with a new history file...). But even without
doing that:

[...]
: 994850317:0;emacs cshrc.loria
: 994850342:0;rl lepois
: 994850341:0;locale
[...]

But this is because host lepois wasn't synchronized, so a very special
case.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Bart Schaefer]

On Jul 12,  2:43pm, Vincent Lefevre wrote:
}
} [...] the history contained about 100 lines (it was just after I used
} a new history file), and $HISTSIZE is 2000 here.

Was there more than one zsh process involved?

} greux:~> diff $HISTFILE temphistfile
} 112c112
} < : 994936533:0;mail
} ---
} > : 994937129:867;mail

This difference could be explained by HIST_IGNORE_DUPS (which you said
in 3981 that you do have set) if you ran the command "mail" twice in
a row.  The in-memory history gets the most recent start-time, but the
file is not re-written unless the command text differs.  I suppose that
could be considered a bug when EXTENDED_HISTORY is set, but there's no
good fix except to save a duplicate in the file even though there is
no duplicate in memory.  And I hadn't realized that INC_APPEND_HISTORY
causes the elapsed-time to be lost from the entries, but that makes
sense because they're written out before the command has finished.

} 116,120c116,119
} < : 994939941:0;m $HISTFILE
} < : 994939999:0;mail
} < : 994940004:0;m $HISTFILE
} < : 994940081:0;mail
} < : 994940743:0;rem
} ---
} > : 994939966:13;m $HISTFILE
} > : 994939999:2;mail
} > : 994940004:8;m $HISTFILE
} > : 994940743:308;rem
} 122d120
} < : 994941319:0;diff $HISTFILE temphistfile
} 
} Is it normal?
} 
} It seems that a "mail" command has disappeared from the history file.

There are more commands in $HISTFILE than in temphistfile, which means
that the command was written to $HISTFILE but is not present in memory.
That's extremely odd unless $HISTFILE was written by two or more shells
(each using INC_APPEND_HISTORY) or unless you have one of the IGNORE_ALL
options set (which you've previously said that you don't).  Hence my very
first question.

I'm curious about lines 113-115.  They have zero elapsed times in both
$HISTFILE and temphisfile (otherwise they'd have showed up as a diff).
So either those were very short commands (executed in less than 1 sec.)
or there are two shells involved and you did the diff in the one that was
started later (so it read part of its history from the first shell).

It's a little bit odd that the start times for the first "m $HISTORY"
commands are different as recorded in $HISTFILE and temphistfile.  Could
be another ignore-dups thing.

I just noticed looking at the history code that using INC_APPEND_HISTORY
acts like SHARE_HISTORY each time $HISTFILE exceeds $[SAVEHIST*1.2]
entries.  That is, the history file is re-read and then written in order
to truncate it back down to $SAVEHIST entries, so any interleaved
entries from multiple simultaneous shells will become interleaved in the
shell that performed the truncation, but remain independent in all the
other shells.  There's no way to predict how often this will happen, or
to which shell, though it will tend to happen in the shell where you're
working most actively.

That also means that if you have HIST_IGNORE_DUPS (ignore duplicates only
if they occur adjacent to one another), the interleaving could cause two
entries that were not initially ignored to become adjacent and thus cause
one of them to be ignored when the file is re-read.  I think.

But neither of those things should have been going on in the example
excerpted above (the file should never yet have been re-read/written).

Anyway, one other thing to remember is that INC_APPEND_HISTORY writes to
$HISTFILE as soon as you press return (or any `accept' binding) for a 
command; it doesn't wait for the command to finish.

} > } It seems to be due to the fact that the time stamps are not in the
} > } increasing order.
} 
} > Can you show an example of this, please?
} 
} This can be done by manually copying commands to the history file
} [... or] because host lepois wasn't synchronized

Aha.  Well, that *shouldn't* make a difference.  The history ring doesn't
actually pay any attention to the timestamps.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

On 12 Jul, Bart Schaefer <schaefer@candle.brasslantern.com> wrote:

> Was there more than one zsh process involved?

Yes, on the same machine of course.

> This difference could be explained by HIST_IGNORE_DUPS (which you said
> in 3981 that you do have set) if you ran the command "mail" twice in
> a row.

I have the following:

  setopt INC_APPEND_HISTORY NO_SHARE_HISTORY
  setopt EXTENDED_HISTORY
  setopt HIST_IGNORE_DUPS NO_HIST_IGNORE_ALL_DUPS
  setopt NO_HIST_ALLOW_CLOBBER HIST_REDUCE_BLANKS
  setopt HIST_IGNORE_SPACE HIST_NO_STORE HIST_NO_FUNCTIONS
  setopt HIST_BEEP

and

HISTSIZE=2000
SAVEHIST=2000
HISTFILE="$HOME2/.zhistory"

($HOME2 is my home on the local hard disk when there is one, otherwise
it has the same value as $HOME.)

>  The in-memory history gets the most recent start-time, but the
> file is not re-written unless the command text differs.  I suppose that
> could be considered a bug when EXTENDED_HISTORY is set, but there's no
> good fix except to save a duplicate in the file even though there is
> no duplicate in memory.  And I hadn't realized that INC_APPEND_HISTORY
> causes the elapsed-time to be lost from the entries, but that makes
> sense because they're written out before the command has finished.

Is there a reason? Why shouldn't they be written out after the command
finishes?

> } 116,120c116,119
> } < : 994939941:0;m $HISTFILE
> } < : 994939999:0;mail
> } < : 994940004:0;m $HISTFILE
> } < : 994940081:0;mail
> } < : 994940743:0;rem
> } ---
> } > : 994939966:13;m $HISTFILE
> } > : 994939999:2;mail
> } > : 994940004:8;m $HISTFILE
> } > : 994940743:308;rem

> There are more commands in $HISTFILE than in temphistfile, which means
> that the command was written to $HISTFILE but is not present in memory.
> That's extremely odd unless $HISTFILE was written by two or more shells
> (each using INC_APPEND_HISTORY) or unless you have one of the IGNORE_ALL
> options set (which you've previously said that you don't).  Hence my very
> first question.

Yes, there were 2 shells (using the same options). I think this is
the same one that executed the mail command, and the other one that
executed the "m $HISTFILE" command. BTW, how about writing a shell
identifier (perhaps the tty?) to the extended history?

> I'm curious about lines 113-115.  They have zero elapsed times in both
> $HISTFILE and temphisfile (otherwise they'd have showed up as a diff).
> So either those were very short commands (executed in less than 1 sec.)

Yes, this is the case (2 echo and 1 wc).

> It's a little bit odd that the start times for the first "m $HISTORY"
> commands are different as recorded in $HISTFILE and temphistfile.  Could
> be another ignore-dups thing.

Perhaps.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Wayne Davison]

On Thu, 12 Jul 2001, Bart Schaefer wrote:
> And I hadn't realized that INC_APPEND_HISTORY
> causes the elapsed-time to be lost from the entries, but that makes
> sense because they're written out before the command has finished.

Yeah.  My original patch wrote the commands out when they finished, but
some folks were expecting the command to be present before it completed
(when sharing the history among multiple shells), so I changed it.  I
suppose there might be ways to try to update the elapsed time values
when a shell rewites the history file, but that's probably too much
complication for too little reward.

> I just noticed looking at the history code that using INC_APPEND_HISTORY
> acts like SHARE_HISTORY each time $HISTFILE exceeds $[SAVEHIST*1.2]
> entries.  That is, the history file is re-read and then written in order
> to truncate it back down to $SAVEHIST entries, so any interleaved
> entries from multiple simultaneous shells will become interleaved in the
> shell that performed the truncation, but remain independent in all the
> other shells.

No, that code creates a separate history buffer to do the rewriting, so
it should not affect the in-memory history (unless there is a bug).

..wayne..

Re: [4.0.2 bug] commands not written to history

[Bart Schaefer]

On Jul 12,  1:58pm, Wayne Davison wrote:
}
} On Thu, 12 Jul 2001, Bart Schaefer wrote:
} > And I hadn't realized that INC_APPEND_HISTORY
} > causes the elapsed-time to be lost from the entries
} 
} Yeah.  My original patch wrote the commands out when they finished, but
} some folks were expecting the command to be present before it completed
} (when sharing the history among multiple shells), so I changed it.

It could write them beforehand with SHARE_HISTORY and afterwards with
only INC_APPEND_HISTORY.  But then the entries would be orded by the
end time rather than the start time in the latter case (not that it
should make any difference operationally).

Anyway, we still haven't managed to address Vincent's original complaint.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

On Fri, Jun 29, 2001 at 16:33:49 +0200, Vincent Lefevre wrote:
> I sometimes write related commands like
> 
> $ cmd1
> $ cmd2
> 
> And several hours/days later, I can recall cmd1 from the history and
> type ^O to recall cmd2 automatically. I don't want to do that in a
> script or in a function, to have full control on these commands (and
> be able to insert commands between cmd1 and cmd2 if need be).
> 
> But sometimes (difficult to say under which conditions), a copy of cmd1
> had been written to the history (as expected), but there is no copy of
> cmd2. That is, ^O gives me another command (instead of cmd2).
[snip]

This problem occurred again, but this time with a local FS, so the
problem can't be related to NFS:

/dev/hda13 on /home type ext2 (rw)

Moreover, the command I got after cmd1 was "startx", which means that
cmd2 (the command that hadn't been written to the history) was the
last command typed in the shell, like in my previous bug report.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [4.0.2 bug] commands not written to history

[Wayne Davison]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 981 bytes --]

On Fri, 29 Jun 2001, Vincent Lefevre wrote:
> It seems that cmd2 simply disappeared from the history; cmd2 probably
> was the last command I typed in the shell, then I logged out, and
> logged in again (thus, the xinit in the history just after cmd1).

I was finally able to reproduce a case where the shell failed to save
the very last command in the history.  It only occurs when the Zle
history is active and the shell gets a signal that causes it to die.
In these circumstances, the save-history code is subtracting 1 from
the maximum number of events that it will save (so that the last,
unfinished line is not written out), but since the code is really
rewriting the history file using an alternate history buffer, the
real result is that it loses the last line in the just-read data.

So, do you know if you were exiting the shell via some kind of signal
rather than typing something like "exit"?  If so, try the attached
patch and see if this fixes the problem.

..wayne..

[-- Attachment #2: fix last-line lossage --]
[-- Type: TEXT/PLAIN, Size: 837 bytes --]

Index: Src/hist.c
--- Src/hist.c	2001/06/28 18:17:14	1.30
+++ Src/hist.c	2001/08/07 19:32:59
@@ -2028,10 +2028,13 @@
 	    Histent remember_hist_ring = hist_ring;
 	    int remember_histlinect = histlinect;
 	    int remember_curhist = curhist;
+	    int remember_histsiz = histsiz;
+	    int remember_histactive = histactive;
 
 	    hist_ring = NULL;
 	    curhist = histlinect = 0;
 	    histsiz = savehist;
+	    histactive = 0;
 	    createhisttable(); /* sets histtab */
 
 	    hist_ignore_all_dups |= isset(HISTSAVENODUPS);
@@ -2044,6 +2047,8 @@
 	    histlinect = remember_histlinect;
 	    hist_ring = remember_hist_ring;
 	    histtab = remember_histtab;
+	    histsiz = remember_histsiz;
+	    histactive = remember_histactive;
 	}
     } else if (err)
 	zerr("can't write history file %s", fn, 0);

Re: [4.0.2 bug] commands not written to history

[Vincent Lefevre]

In article <Pine.LNX.4.33L2.0108071235060.3311-200000@phong.blorf.net>,
   Wayne Davison <wayned@users.sourceforge.net> wrote:

> So, do you know if you were exiting the shell via some kind of signal
> rather than typing something like "exit"?

I never type "exit". I generally quit zsh with Ctrl-D. But sometimes
I quit the window manager (fvwm), which sends a signal to zsh AFAIK.
I've just reproduced the bug by doing that. So, I think this was the
problem.

> If so, try the attached patch and see if this fixes the problem.

Thanks, I'll try it...

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA