reading/saving history file dependent on isset(RCS)

reading/saving history file dependent on isset(RCS)

[Greg Klanderman]

Hi, can someone explain the thinking behind reading and saving of the
history file being dependent on isset(RCS)?  The code predates CVS..
Seems like if you've set HISTFILE/SAVEHIST, it should honor that.

I did find this partially documented, in section "5.1 Startup/Shutdown Files":

| Note also that the RCS option affects the saving of history files,
| i.e. if RCS is unset when the shell exits, no history file will be
| saved.

but it does not document that reading the history file is similarly
conditioned on that option.

thanks,
Greg

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

[Benjamin R. Haskell]

On Wed, 19 Oct 2011, Greg Klanderman wrote:

>
> Hi, can someone explain the thinking behind reading and saving of the 
> history file being dependent on isset(RCS)?  The code predates CVS.. 
> Seems like if you've set HISTFILE/SAVEHIST, it should honor that.
>
> I did find this partially documented, in section "5.1 Startup/Shutdown Files":
>
> | Note also that the RCS option affects the saving of history files,
> | i.e. if RCS is unset when the shell exits, no history file will be
> | saved.
>
> but it does not document that reading the history file is similarly 
> conditioned on that option.

This bit me last time I was trying to debug someone's history-related 
issues.  I found that passage, too, (eventually), which is why I didn't 
complain then.  I don't understand the rationale for the conditioning. 
I'd be interested in seeing this changed if there's not a good reason 
for its being conditioned by default.

-- 
Best,
Ben

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

[Bart Schaefer]

On Oct 19,  2:48pm, Benjamin R. Haskell wrote:
} Subject: Re: reading/saving history file dependent on isset(RCS)
}
} On Wed, 19 Oct 2011, Greg Klanderman wrote:
} 
} > Hi, can someone explain the thinking behind reading and saving of the 
} > history file being dependent on isset(RCS)?  The code predates CVS.. 

AFAICT "it has always been that way."  I have sources dating back to
version 2.4 and it's already in there.

} > I did find this partially documented, in section
} > "5.1 Startup/Shutdown Files":
} >
} > | Note also that the RCS option affects the saving of history files,
} > | i.e. if RCS is unset when the shell exits, no history file will be
} > | saved.
} >
} > but it does not document that reading the history file is similarly 
} > conditioned on that option.

There isn't a default setting for HISTFILE, so if no startup files are
read there's no way for the shell to know what history file to read.
That's not "conditioned on" the option, it's just a side-effect.
 
} This bit me last time I was trying to debug someone's history-related 
} issues.  I found that passage, too, (eventually), which is why I didn't 
} complain then.  I don't understand the rationale for the conditioning. 
} I'd be interested in seeing this changed if there's not a good reason 
} for its being conditioned by default.

I'm pretty sure that the reasoning is that if the shell didn't read the
history file in the first place (which it could not possibly have, see
above) then it's likely to destroy information if it writes the file
on exit.  So the user has to deliberately clear the option if he wants
the shell to behave like one that started up with the option off.

-- 
Barton E. Schaefer

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

[Greg Klanderman]

>>>>> On October 20, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> There isn't a default setting for HISTFILE, so if no startup files are
> read there's no way for the shell to know what history file to read.
> That's not "conditioned on" the option, it's just a side-effect.

But it's not just a side-effect; the call to readhistfile() is
actually conditioned on 'isset(RCS)', so if my .zshenv sets HISTFILE
and also 'setopt norcs', it does not read my HISTFILE.

Based on there being no default setting for HISTFILE, can the
isset(RCS) check can be safely removed for the readhistfile() call?

> I'm pretty sure that the reasoning is that if the shell didn't read the
> history file in the first place (which it could not possibly have, see
> above) then it's likely to destroy information if it writes the file
> on exit.  So the user has to deliberately clear the option if he wants
> the shell to behave like one that started up with the option off.

Likewise, if there is no default setting of HISTFILE, can we safely
remove the isset(RCS) checks for the savehistfile() calls?

It seems useful to consider two cases:

1. NORCS gets set from the command line (zsh -f): in this case
   HISTFILE is not set, and the isset(RCS) checks are superfluous.

2. NORCS gets set from some startup file, to inhibit later startup
   files from loading: in this case, if you've set HISTFILE, it seems
   reasonable to honor it for both reading and writing the history.

The argument about not clobbering a file that was not read in the
first place only holds if the shell brokenly decided not to read the
file that was requested via the user having set HISTFILE.

Greg

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

[Bart Schaefer]

On Oct 20, 12:55pm, Greg Klanderman wrote:
} 
} Based on there being no default setting for HISTFILE, can the
} isset(RCS) check can be safely removed for the readhistfile() call?

Something you said tripped a synapse.

No, this can't be safely removed.

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.

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

[Greg Klanderman]

>>>>> On October 21, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Oct 20, 12:55pm, Greg Klanderman wrote:
> } 
> } Based on there being no default setting for HISTFILE, can the
> } isset(RCS) check can be safely removed for the readhistfile() call?

> Something you said tripped a synapse.

> No, this can't be safely removed.

> 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?  In that case, if
/etc/zshenv were to set HISTFILE/SAVEHIST, then the HISTFILE should
not get clobbered.  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.

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?  In that
case, 'zsh -f' would inhibit history reading/saving, but having
'setopt norcs' in one of your init scripts would not.

thanks,
Greg

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

[Bart Schaefer]

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@brasslantern.com> 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.