Re: issues with saving history to file

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Mar 13, 2024 at 8:05 AM Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
>
> With zsh 5.9:
>
> cventin:~> zsh -f
[set up history parameters and options]
> cventin% exit
> cventin:~> ls ~/.histfile
> ls: cannot access '/home/vlefevre/.histfile': No such file or directory
>
> However, if I use INC_APPEND_HISTORY instead of APPEND_HISTORY, the
> history is saved.

This is because history is being incrementally saved (as the option
name indicates) rather than being held only in memory until the shell
is preparing to exit.  APPEND_HISTORY just means that if the history
is saved, it will be added to the history file (up to $SAVEHIST)
instead of overwriting it.

> According to the zsh(1) man page:
>
>   Note also that the RCS option affects the saving of history files,
>   i.e. if RCS is unset when the shell exits, no history file will be
>   saved.
>
> But the difference between INC_APPEND_HISTORY and APPEND_HISTORY is
> not documented concerning this point.

Congratulations, you've found another place where documentation of
feature X was not updated upon the introduction of newer feature Y.
The doc for history is littered with these because it's been around
longer than just about anything: HISTFILE is still documented as only
being used at shell exit.

Someone else can patch it this time.

> Also, I do not see the point of not saving the history when RCS is set.

It is saving when RCS is set, and not when RCS is not set (no_RCs).

This is done because of the handling of $SAVEHIST, not to mention the
various duplicate handling options.  When no_RCs, the history has
(presumably) not been read in at startup in the first place, so it
won't have been merged with the interactive state.  If written out
when never read in, the $SAVEHIST size limit could cause contents to
be lost that otherwise would not be.  (Frobbing the RCs option during
later shell operation is effectively undefined behavior, too difficult
to keep track of.)

> IMHO, HISTFILE should just be unset by default; but if the user sets
> this parameter, I suppose that the goal is to save the history.

The goal might be to read the history, not to write it.

In any case we've had several go-rounds on this (and on the "right
way" to set HISTSIZE vs. SAVEHIST) without coming to any consensus
differing from the existing behavior.

> Without INC_APPEND_HISTORY, the man page doesn't document when
> precisely the history is saved. For instance, what happens if one
> has a "print -s ..." in the .zlogout file?

It'd expect it to be lost, because the history is saved before
.zlogout is read.   Try it and let us know.  Maybe it dumps core.

> Moreover, with INC_APPEND_HISTORY, "print -s" does not put the entry
> in the history file immediately, only after the next accept-line.

"print -s" doesn't write to the HISTFILE and isn't documented that
way.  It explicitly says "Place the results in the history list".  The
"history list" is the internal shell history, not the file.  The file
is updated from the internal list either at shell exit or
(incappendhistory) when a line is entered (i.e., conceptually upon
accept-line, though in practice upon entering a complete command since
updating at PS2 would leave an incomplete entry).  You can use the
zshaddhistory hook to confirm this.