From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3) with ESMTP id EAA23223 for ; Thu, 11 Apr 1996 04:11:26 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id OAA15207; Wed, 10 Apr 1996 14:04:23 -0400 (EDT) Resent-Date: Wed, 10 Apr 1996 14:04:23 -0400 (EDT) From: Anthony Heading Message-Id: <199604101803.TAA00736@gmp-etpres1.uk.jpmorgan.com> Subject: Re: History file locking? To: schaefer@z-code.ncd.com Date: Wed, 10 Apr 1996 19:03:33 +0100 (BST) Cc: zsh-workers@math.gatech.edu In-Reply-To: <960410101252.ZM16289@zyrcon.z-code.com> from "Barton E. Schaefer" at Apr 10, 96 10:12:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1ccAY3.0.Uj3.cW_Qn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/912 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bart wrote: > I think this one falls in the category of "if you can do it with an > external process, it doesn't belong in the shell". I understand the principle. And maybe you're right. But zsh doesn't rely much on /bin/[ for example. Defence to the charge of featuritis: o Not very much code o Merely providing public access to a feature motivated by internal need o Internalising would often allow more reliable/easier lock release. o Lockfiles are a natural adjunct to shell programming o Resulting portability of lockfile-utilising user scripts One could bundle a separate implementation of 'lockfile' with zsh, I guess. But that feels a bit extreme. Just because zsh is maybe biased toward the 'bloated' end of the shell market doesn't mean we need to become reactionary neo-minimalists to compensate. Who uses rc anyhow? I dunno. Just thought I'd flag the idea, no more than that. Anthony