From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7849 invoked from network); 18 Mar 2005 17:58:18 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Mar 2005 17:58:18 -0000 Received: (qmail 86642 invoked from network); 18 Mar 2005 17:58:12 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Mar 2005 17:58:12 -0000 Received: (qmail 28029 invoked by alias); 18 Mar 2005 17:58:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21011 Received: (qmail 28014 invoked from network); 18 Mar 2005 17:58:08 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Mar 2005 17:58:08 -0000 Received: (qmail 86326 invoked from network); 18 Mar 2005 17:58:08 -0000 Received: from dsl3-63-249-88-2.cruzio.com (HELO dot.blorf.net) (63.249.88.2) by a.mx.sunsite.dk with SMTP; 18 Mar 2005 17:58:04 -0000 Received: by dot.blorf.net (Postfix, from userid 1000) id AEC72AB5B; Fri, 18 Mar 2005 09:58:02 -0800 (PST) Date: Fri, 18 Mar 2005 09:58:02 -0800 From: Wayne Davison To: Peter Stephenson Cc: zsh-workers@sunsite.dk Subject: Re: revisiting history-file rewriting Message-ID: <20050318175802.GD5500@blorf.net> References: <20050316204059.GA1298@blorf.net> <200503181049.j2IAn96p007683@news01.csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503181049.j2IAn96p007683@news01.csr.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 On Fri, Mar 18, 2005 at 10:49:08AM +0000, Peter Stephenson wrote: > How would this change the result when multiple shells exit at once? > I'm not entirely clear how the locking affects the fact that multiple > shells want to rewrite the file in this case. It doesn't change that behavior except to make it safer -- if zsh is forcefully killed it might be in the middle of writing out a new copy of the history file instead of a truncated version of the real history file. Note also that for anyone using one of the history-appending options that I've already eliminated the multi-shell locking contention at system shutdown time because zsh no longer tries to rewrite the history file on a kill signal (and doesn't need to touch the history file at all if it has no history data left to append). ..wayne..