From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 281 invoked by alias); 24 Oct 2011 17:08:43 -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: 29854 Received: (qmail 29052 invoked from network); 24 Oct 2011 17:08:42 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <111024100817.ZM7342@torch.brasslantern.com> Date: Mon, 24 Oct 2011 10:08:17 -0700 In-reply-to: Comments: In reply to Greg Klanderman "Re: reading/saving history file dependent on isset(RCS)" (Oct 21, 11:26am) References: <20127.6190.501587.50858@gargle.gargle.HOWL> <111020001018.ZM9637@torch.brasslantern.com> <111021054029.ZM15446@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: reading/saving history file dependent on isset(RCS) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 21, 11:26am, Greg Klanderman wrote: } Subject: Re: reading/saving history file dependent on isset(RCS) } } >>>>> On October 21, 2011 Bart Schaefer wrote: } } > I now seem to recall that this was added when sourcing /etc/zshenv was } > exempted from NO_RCS. If the system zshenv sets HISTFILE or SAVEHIST, } > then you can get bad side-effects even with "zsh -f" unless NO_RCS } > suppresses history file management. } } Thank you for looking into this Bart. Do you still object if both the } guard against reading and saving are removed? The problem in part is that "-f" is supposed to mean "fast". If the global zshenv sets HISTFILE and someone has 10,000+ lines of saved history (and yes, some people do) then "zsh -f" suddenly becomes very slow and bloated. } In that case, if } /etc/zshenv were to set HISTFILE/SAVEHIST, then the HISTFILE should } not get clobbered. In what way is it not clobbered? Commands added to history during the shell session will be saved when they weren't before, and some history may consequently roll off the top; or what if /etc/zshenv also sets SAVEHIST or HISTSIZE to something smaller than the user's value? What if the user normally DOES NOT save history? What if the history file is shared among multiple running shells? } I guess given the multitude of ways one could get } shot in the foot via stuff in /etc/zshenv, guarding against just this } one seems a bit pointless, but I can deal with it. Most of the ways one can get messed up by /etc/zshenv don't get written to a file or propagated around by runtime sharing. } Hmm one other proposal for you to consider - how about changing the } logic to use the value of isset(RCS) from *before* any init scripts } were loaded to condition reading/saving the history file? That has some promise, but then how do you give the ability to override it to someone who *wants* to turn back on saving of the history? However, at the least we should put an explanation of all this in the FAQ or the docs.