From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19617 invoked by alias); 14 Jun 2010 14:17:16 -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: 28040 Received: (qmail 5416 invoked from network); 14 Jun 2010 14:17:15 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 14 Jun 2010 15:16:26 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: zsh doesn't load HISTFILE from readonly directory Message-ID: <20100614151626.185ba382@csr.com> In-Reply-To: <20100614150521.068ec280@csr.com> References: <20100614150521.068ec280@csr.com> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 14 Jun 2010 14:16:26.0264 (UTC) FILETIME=[2CC6A180:01CB0BCC] X-Scanned-By: MailControl A_09_40_00 (www.mailcontrol.com) on 10.71.0.139 On Mon, 14 Jun 2010 15:05:21 +0100 Peter Stephenson wrote: > On Sun, 13 Jun 2010 13:17:37 +0000 (UTC) > J=C3=B6rg Sommer wrote: > > if the directory, containing the history file, is not writeable, zsh > > doesn't load the data and I've not history. >=20 > Yes, it's returning after not being able to lock the file. This is > unhealthy because (1) there's no error, which might be arguable for > normal interactive history but is certainly wrong for an explicit "fc > -R" (2) there's no reason why it shouldn't just read the history. >=20 > Not immediately sure how wide the scope of the fix should be. Get > locking to check if the file is not writeable for some reason (which > is a different test from checking if it can be locked)? That's no good. In a case like this (where the problem is directory permissions) we might well still be able to write to the file. However, as zsh wouldn't be able to lock it, it would refuse to write to it. (There's a subtlety that fcntl() file locking might still work but if you have inconsistent file locking options you're already stuffed.) > Or should > we simply issue a warning when and continue any time we can't lock > the file? So, as long as we narrow this to make a check for why we couldn't create the lock (EACCES in this case) maybe this is the right way to go after all? We still need to decide when we should print an error. I would be tempted to do it every time. --=20 Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, = UK Member of the CSR plc group of companies. CSR plc registered in England and= Wales, registered number 4187346, registered office Churchill House, Cambr= idge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom