Re: histroy file being truncated (konsole with multiple shells context)

[Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>]

On Wed, Sep 29, 2004 at 09:39:24PM -0700, Bart Schaefer wrote:
> On Wed, 29 Sep 2004, Wayne Davison wrote:
> > Updating a .new file and then moving it into place would be a safer
> > way to ensure that the history file never gets truncated.
> 
> On the other hand, in that case the changes get lost entirely, which
> might be just as confusing.

I meant that the rewrite would use the .new file after the original
history file got the appended history lines written onto the end of it.
Thus, for people who use one of the history-appending options, they
wouldn't see any loss of history unless the shell didn't even have time
to append its history.  How the shell would work if no history appending
is enabled is an interesting question -- I tend to think that since only
one shell's history "wins", that it doesn't matter if the shell's
history gets lost due to another shell overwriting its file or if it
gets lost due to not having enough time to finish its history update
(assuming that multiple zshs are all shutting down at the same time).

> So a signal in the middle of that rewrite would still be an issue,
> even if we change the exit-time behavior.

Yes, but that's a manageable case since only one zsh is in the middle of
rewriting the file instead of all "N" zsh's that received a kill signal
frantically trying to rewrite the history file before they get killed by
a follow-up signal.

So, I think the change in signal handling to avoid a cleanup rewrite of
the history file on reception of a death signal is probably the best
first step to pursue.  After that, the decision to use a .new file or
not would probably not make much of a difference in actual practice.

..wayne..