Re: zsh: corrupt history file

["Daniel Shahaf" <d.s@daniel.shahaf.name>]

Eric Cook wrote on Thu, 30 Jul 2020 03:56 +00:00:
> On 7/29/20 7:07 PM, Daniel Shahaf wrote:
> > I guess you mean adding such warnings to zshparam(1)?  In which case,
> > perhaps adding them to bin_typeset() would be more effective?  As in:
> >
> > % export HISTORY=foo
> > zsh:1: warning: $HISTORY should not be exported; use 'typeset HISTORY=foo' instead
> >
> > (and if someone actually needs to export $HISTORY for whatever reason,
> > we can make -h suppress the warning)
>
> That is indeed what i meant, but your solution has two problems in the
> example of PS1. if it is in the environment when zsh starts and the
> user doesn't set it, you experience the issue of another shell's
> escape sequences being used that typeset won't warn of since it isn't
> being used.

What I proposed would address the issue of zsh exporting $PS1 and some
other shell then using zsh's value (e.g., «export PS1='%# '; dash»).  What
you're describing is the converse problem and would need to be fixed
separately.

> the second issue being software like python's virtualenv
> being written under the assumption that exporting PS1 won't cause an
> warning message in the shells their activation script is written for,
> would need to now account for that.

Isn't that a bug in their code that they should fix?  PS1 shouldn't be exported.

Incidentally, if they do the equivalent of «env PS1=foo zsh», then they
won't be affected because that doesn't go through bin_typeset() in the
first place.  They'd only be affected if they somehow cause the 'export'
or 'typeset' builtins to be executed (e.g., by setting up their own
$ZDOTDIR).

> I know i have offered critiques yet no solutions, but i don't think
> either of the suggestions is ideal personally.