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

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

Marlon Richert wrote on Tue, Apr 27, 2021 at 14:42:47 +0300:
> On Tue, Apr 27, 2021 at 2:55 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > On Mon, Apr 26, 2021 at 12:30 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > >
> > > > What kind of approach would be acceptable?
> > >
> > > I think you've basically run into the halting problem here
> >
> > Consequently we need to decide collectively whether we're just
> > rejecting "zrestart" as impossible, or if there's a sub-optimal
> > solution we can agree on.  I suspect that executing the entire startup
> > twice in order to be sure it'll work once, is not one we'll agree on.
> >
> > Not really a solution, but an interesting (?) observation:
> >
> > If you start an interactive shell in the background, it will stop when
> > it tries to print the first prompt:
> >
> > % echo $$
> > 277859
> > % Src/zsh -f &
> > [1] 277861
> > %
> > [1]  + suspended (tty output)  Src/zsh -f
> >
> > You can then do:
> >
> > % exec fg
> > [1]  + continued  Src/zsh -f
> > % echo $$
> > 277861
> > %
> >
> > Now you're at the prompt for the previously backgrounded shell.  If
> > you exit from that, the parent is gone.
> >
> > So if you had some way to detect that a backgrounded shell had
> > actually reached the PS1 prompt, you could cause the parent shell to
> > replace itself.
> 
> Failing that, perhaps a better option would just be to add a note in
> the newuser .zshrc to use `zsh` or `zsh && exit` to apply changes?
> 
> Or perhaps zrestart could be just this:
> 
> zrestart() {
>   exec zsh
> }
> 
> At least then the user has no risk of mistyping the argument to exec.

Hang on; these are two separate problems.

1. «exec typo».  We could add a setopt that makes this not kill the
shell.  That'd be analogous to execve(3):

    RETURN VALUE
           On success, execve() does not return, on error -1 is returned, and errno is set appropriately.

2. «exec zsh» that then immediately exits non-zero.  I'd argue this
should be fixed in the terminal emulator by configuring it to not close
a tab when the command in that tab exited non-zero — for instance,
because that usually causes the command's stderr to be lost.  (Compare
tmux's remain-on-exit option, albeit that one isn't conditional on the
exit code.)

----

For (2), there may be some fancier way along the lines of:
.
    # Arrange for the timestamp of $SOME_WELL_KNOWN_FILENAME to
    # approximate the last successful start of an interactive shell
    pre${either_cmd_or_exec_but_I_forget_which}() {
        touch -- $SOME_WELL_KNOWN_FILENAME
        add-zsh-hook -d -- … ${funcstack[1]}
    }
.
and then in .zshrc:
.
    if (( ${foo}++ == 0 )) && [[ ${ZDOTDIR:-${HOME:-/dev/null}}/.zshrc -nt $SOME_WELL_KNOWN_FILENAME ]]; then
        eval source -- ${(q)${ZDOTDIR:-${HOME}}/.zshrc
        case $? in
            (0) return 0;;
            ((#b)(*)) add-zsh-hook -d … pre${either_cmd_or_exec_but_I_forget_which}; return ${match};;
        esac
    fi
    unset ${foo} # "Run only on the topmost recursive invocation" mechanism

But I think deliberately ignoring errors like this falls under
"possible, but not advisable".

Again, that's just a sketch / pseudocode, not an actual tested solution.

The /dev/null trick is just to avoid stat()ing /.zshrc if ZDOTDIR and
HOME are both unset.

Cheers,

Daniel