From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3863 invoked from network); 12 Jul 2001 20:59:25 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 12 Jul 2001 20:59:25 -0000 Received: (qmail 27312 invoked by alias); 12 Jul 2001 20:59:14 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 4035 Received: (qmail 27296 invoked from network); 12 Jul 2001 20:59:13 -0000 Date: Thu, 12 Jul 2001 13:58:42 -0700 (PDT) From: Wayne Davison X-X-Sender: To: Bart Schaefer Cc: Vincent Lefevre , Subject: Re: [4.0.2 bug] commands not written to history In-Reply-To: <1010712174700.ZM271@candle.brasslantern.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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..