From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17477 invoked from network); 5 May 1999 10:52:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 May 1999 10:52:38 -0000 Received: (qmail 27351 invoked by alias); 5 May 1999 10:52:28 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6223 Received: (qmail 27344 invoked from network); 5 May 1999 10:52:24 -0000 From: "Bart Schaefer" Message-Id: <990505035139.ZM32285@candle.brasslantern.com> Date: Wed, 5 May 1999 03:51:39 -0700 In-Reply-To: <9905050811.AA13411@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: Upcoming: handy history extensions" (May 5, 10:11am) References: <9905050811.AA13411@ibmth.df.unipi.it> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@sunsite.auc.dk Subject: Re: Upcoming: handy history extensions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 5, 10:11am, Peter Stephenson wrote: } Subject: Re: Upcoming: handy history extensions } } > Another issue is history-file locking. I think we want to lock the } > file when doing incremental updating (especially since re-writing } > now occurs much more frequently). } } [...] checking for fcntl/F_SETLKW etc., lockf/F_LOCK etc., flock/LOCK_SH } etc. should be straightforward [...] It would be much better to go with a file-based locking protocol, like the one in procmail. I believe there's a freely-reusable module in procmail to create those locks; there's a copy of same in the mush mailer sources (ftp://cse.ogi.edu/pub/mush) if the one in procmail is too ugly. } Then there's the whole Lockdaemon From Hell saga, which we had } better just forget about. If you don't want your shell locking up your entire machine, you'd better not forget about it ... which is why using any of the kernel-based locking mechanisms is right out. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com