zsh-users
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-users@math.gatech.edu
Subject: How to make APPENDHISTORY useful?
Date: Thu, 13 Feb 1997 14:29:20 -0800	[thread overview]
Message-ID: <970213142920.ZM22919@candle.brasslantern.com> (raw)

`APPEND_HISTORY'
     If this is set, zsh sessions will append their history list to the
     history file, rather than overwrite it.  Thus, multiple parallel
     zsh sessions will all have their history lists added to the
     history file, in the order they are killed.

This sounds useful, but in practice it's not very helpful.  Here's why:

Suppose I set HISTSIZE to be more lines than SAVEHIST.  Now every time a
shell exits, it appends its history to the file and then truncates the
file to SAVEHIST lines.  Result: Same as if history weren't appended.

Now suppose I set SAVEHIST to be more lines than HISTSIZE.  Every time a
shell exits, it appends its history to the file, leaving some lines from
other shells at the top.  So far so good.  But when I start a new shell,
it reads in all that history and then truncates it to HISTSIZE.  Result:
Same as if history hadn't been appended.

You get the illusion that something good is happening if you start with
an empty file and run a few shells that don't put SAVEHIST lines into the
history before exiting; but once the file gets full you're back to one of
the states described above.

A logical thought would be to start out with HISTSIZE set to at least as
large as SAVEHIST, and then just before saving the history file, reset
HISTSIZE to something less than SAVEHIST, so that the tail end of this
shell's history would mix with whatever is already in the file.  But that
doesn't work because the history file is written *before* the exit traps
execute and before zlogout files are read, so there's no place to put the
re-assignment to HISTSIZE.

To get the *effect* of reducing HISTSIZE before saving, you have to put
a bunch of `fc' commands in your exit trap or zlogout.  But if you have
to do that anyway, then you can *explicitly* append, so APPEND_HISTORY is
of no benefit in that case.

What am I missing here?


             reply	other threads:[~1997-02-13 23:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-02-13 22:29 Bart Schaefer [this message]
1997-02-13 23:12 ` Greg Badros
1997-02-13 23:53 ` Wayne Davison
1997-02-14  1:10   ` Bart Schaefer

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=970213142920.ZM22919@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=schaefer@nbn.com \
    --cc=zsh-users@math.gatech.edu \
    /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).