Re: [RFC][PATCH] Add zrestart()

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Marlon Richert wrote on Mon, 26 Apr 2021 19:03 +00:00:
> On Mon, Apr 26, 2021 at 6:22 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > > +{
> > > +  # Some users export $ZDOTDIR, which can mess things up.
> > > +  local zdotdir=$ZDOTDIR
> > > +  unset ZDOTDIR
> >
> > More importantly, I don't see any reason to munge $ZDOTDIR in the first
> > place.  It amounts to second-guessing the user.
> 
> It's a workaround for the following problem that I've observed in the wild:
> 1. $HOME/.zshenv does `export ZDOTDIR=foo` and <bar>.
> 2. $ZDOTDIR/.zshrc does something that relies on <bar> having happened.
> 3. User calls zrestart (or just `exec zsh`, for that matter).
> 4. The new shell now looks for foo/.zshenv instead of $HOME/.zshenv,
> but no such file exits.
> 5. .zshrc throws an error because <bar> hasn't happened in this shell.

If the user set up their dotfiles such as typing «zsh» at the prompt
doesn't launch zsh, that's not your problem to fix.  Drop the unset.

(And anyway, even if you didn't drop the unset, you'd still have to make
it local to the function in case it returns.)

> > > +  local err="$(zsh --interactive --monitor --zle -c '' 2>&1 > /dev/null)"
> >
> > Also, I think it's quite a stretch to describe this line as "_tests_
> > whether the shell is able to restart".
> 

Care to comment about the part of my answer before the "Also", which you
had snipped?

> I originally had `zsh -fn <all the dotfiles>`, along the lines of what
> was suggested earlier, but that test can fail on a valid dotfile that
> uses dynamically named dirs.

A minimal example of this would not be out of place.

> Plus, if any dotfile sources other files,
> those files aren't checked this way at all. The approach above is the
> only one I've found so far that appears to be completely reliable in
> determining whether the shell can start up successfully.
> 
> 
> > This line executes a whole bunch of code you have no control over.
> 
> It is, however, exactly the code we want to test here.
> 

I'm aware.  However, you aren't "testing" it, you are *running* it.

First, that means the docs are wrong.

Second, that code might do things that are inappropriate for the use-case
of "testing" the startup code.

Or, in other words: the trick is to throw the bathwater out and
keep the baby.  Keeping *both* the baby and the bathwater isn't an
ideal solution.

> 
> > I don't think that's an acceptable approach.
> 
> What kind of approach would be acceptable?

I think you've basically run into the halting problem here, so, try
a different universe.  The current one was compiled with some funny
#define's.

Daniel