zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Bug with handling of SAVEHIST?
Date: Wed, 8 Sep 2021 14:20:00 -0700	[thread overview]
Message-ID: <CAH+w=7axnrSf2FqCwgBPBdWk+zc3uWCBiUHpSsd2hSLfDWJrOw@mail.gmail.com> (raw)

The doc for "fc" says:
     'fc -R' reads the history from the given file, 'fc -W' writes the
     history out to the given file, and 'fc -A' appends the history out
     to the given file.  If no filename is specified, the $HISTFILE is
     assumed.  If the -I option is added to -R, only those events that
     are not already contained within the internal history list are
     added.  If the -I option is added to -A or -W, only those events
     that are new since last incremental append/write to the history
     file are appended/written.  In any case, the created file will have
     no more than $SAVEHIST entries.

That implies that:

% SAVEHIST=0; fc -W

should truncate the file, but in fact it does not, because
savehistfile() is over-optimized to a no-op when savehistsiz==0.  (I
assume this is intended to prevent accidentally clobbering the history
on logout.)

However, this also doesn't work:

% SAVEHIST=1; fc -W

The entire current in-memory shell history is always written to the
file when ((SAVEHIST > 0)).

Digging in, savehistfile() pays attention to savehistsiz only when the
HFILE_FAST bit is passed, and bin_fc() never uses that bit; it is used
only by hbegin() and hend() to handle incremental history, and even
then savehistsiz is only compared in order to disable HFILE_FAST again
if too many incremental updates have been done.

There seems to be an assumption that SAVEHIST will never be smaller
than HISTSIZE, and as far as I can tell this has been the case for as
far back as there are git revisions to look through ... despite the
documentation explicitly discussing that scenario for added safety
when using HIST_EXPIRE_DUPS_FIRST.

Am I missing something?  Is this just something we should correct in
the documentation?


                 reply	other threads:[~2021-09-08 21:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7axnrSf2FqCwgBPBdWk+zc3uWCBiUHpSsd2hSLfDWJrOw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).