From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15279 invoked by alias); 10 Nov 2011 03:51:40 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16566 Received: (qmail 1800 invoked from network); 10 Nov 2011 03:51:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <111109195118.ZM6411@torch.brasslantern.com> Date: Wed, 09 Nov 2011 19:51:18 -0800 In-reply-to: <20111109222020.GB10120@devbox> Comments: In reply to Eugene Dzhurinsky "delay in exitting from zsh shell" (Nov 10, 12:20am) References: <20111109222020.GB10120@devbox> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: delay in exitting from zsh shell MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Nov 10, 12:20am, Eugene Dzhurinsky wrote: } } Hello, I'm facing the strange issue - when I run zsh shell and eventually try } to exit from it - it takes some time (3-5 seconds) between I hit Ctrl+D or } type "exit" in shell prompt. } } After some experiments I realized that if I remove .histfile - then } ZSH exists immediately, as supposed. This tends to imply that what's taking those 3-5 seconds is searching your history file for duplicate entries in order to enforce the hist_save_no_dups option. Also, inc_append_history may allow the file to grow to up to 10500 lines for a SAVEHIST of 10000, and those extra lines will be trimmed at shell exit. In more detail, when you use inc_append_history and/or share_history along with hist_save_no_dups, zsh re-reads and de-duplicates the entire file from disk after it has obtained a lock for it, rather than just dumping out the history that is already in memory, because it can't know if some other shell has appended something new to the file before the lock was obtained. The speed of the disk is inconsequential to the CPU expended doing the deduplication.