Re: reading/saving history file dependent on isset(RCS)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 21, 11:26am, Greg Klanderman wrote:
} Subject: Re: reading/saving history file dependent on isset(RCS)
}
} >>>>> On October 21, 2011 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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.