From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5252 invoked by alias); 28 Oct 2011 14:29:03 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29882 Received: (qmail 8863 invoked from network); 28 Oct 2011 14:29:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <111028072853.ZM20113@torch.brasslantern.com> Date: Fri, 28 Oct 2011 07:28:53 -0700 In-reply-to: Comments: In reply to Mikael Magnusson "Re: [PATCH] EXTENDED_HISTORY documentation typo" (Oct 27, 9:13pm) References: <20100328235931.GA23061@ruderich.org> <111027085718.ZM18523@torch.brasslantern.com> <111027115013.ZM19042@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: [PATCH] EXTENDED_HISTORY documentation typo MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 27, 9:13pm, Mikael Magnusson wrote: } Subject: Re: [PATCH] EXTENDED_HISTORY documentation typo } } On 27 October 2011 20:50, Bart Schaefer wrote: } > On Oct 27, 6:12pm, Mikael Magnusson wrote: } > } } > } 5 18:06 0:00 setopt incappendhistory } > } 6 18:06 0:00 cat /tmp/test } > } 7 18:06 0:00 setopt extendedhistory } > } 8 18:06 0:00 cat /tmp/test } > } 9 18:06 0:05 sleep 5 } > } 10 18:07 0:00 cat /tmp/test } } Hm? I ran the sleep after I did setopt extendedhistory. Note also that } the time delta 0:05 is output by history -dD but isn't stored in the } history file. You didn't quote the histfile excerpt: } } setopt extendedhistory } : 1319731616:0;cat /tmp/test } : 1319731618:0;sleep 5 } : 1319731624:0;cat /tmp/test Ah, I see. You've found a conflicting feature -- I can't call it a bug -- with INC_APPEND_HISTORY (which will also affect SHARE_HISTORY). The history entry is written out in hend() as soon as the command line is accepted for execution, but the elapsed time isn't (clearly cannot be) recorded until the call to hbegin() after the command has finished. The HISTFILE is never re-written when it's being appended on the fly, so there is no opportunity for the elapsed time to be updated. Particularly with respect to SHARE_HISTORY there's really no way to fix this -- to be useful, the history has to be shared before the elapsed time is known. Since SHARE and INC_APPEND are handled in the same code, I'm reluctant to suggest that we attempt to change this behavior. The same thing happens when the shell exits because of an "exec": There's no hbegin() call after that final command, so the elapsed time is never logged. : 1319811645:3;sleep 3 : 1319811651:0;exec sleep 9 This should at least be documented. In fact it's even slightly worse (?) than what I just described -- if the file happens to be locked at the instant the append is attempted, zsh simply skips the operation for speed/responsiveness and writes all entries after the *next* command finishes (or the shell exits). In that case the duration of any command whose write was postponed will in fact be recorded. The upshot is that the elapsed time is unreliable if the INC_APPEND_HISTORY or SHARE_HISTORY options are set. (I was wrong about order dependence on setopt extendedhistory; the shell DOES record the elapsed time even when not saving it. I'm surprised no one corrected me on that.) There's one further thing pursuant to another thread: If you setopt INC_APPEND_HISTORY, then the history file does get updated on the fly even though NO_RCS may prevent it being written at shell exit. There are, obviously, an incredible number of these obscure setopt interactions that it's very difficult to track and document.