On Wed, Apr 07, 2021 at 08:15:18PM +0200, Mikael Magnusson wrote:
> On 4/7/21, Marlon <marlon.richert@xxxxxxxxx> wrote:
> >
> >> On 5. Apr 2021, at 22.44, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> >>
> >> On 4/5/21, Marlon Richert <marlon.richert@xxxxxxxxx> wrote:
> >>> #
> >>> # Type `zrestart` to safely apply changes after editing this file.
> >>> #
> >>> zrestart() {
> >>> local zshrc=${ZDOTDIR:-$HOME}/.zshrc
> >>> print -P "Validating %U$zshrc%u..."
> >>> zsh -nf $zshrc ||
> >>> return
> >>>
> >>> print -P 'Restarting Zsh...'
> >>> zsh -l &&
> >>> exit
> >>> }
There are two problems with `zsh -l && exit':
1) every zrestart invocation as written consumes PID space (so not
really a restart);
2) if the last job of the last zsh in a zrestart chain has a non-zero
exit status (e. g. WIFSIGNALED or falsey), and that zsh is ordered to
exit, it will return that exit status, breaking the zrestart chain. The
user would likely interpret this as "wow, my ^D doesn't work!".
I don't know how to write zrestart in plain zsh robustly enough to be
worthy of inclusion in the default .zshrc. Personally I just do
alias zz='exec zsh'
or
alias ZZ='exec zsh'
and that's it, but that's too minimalistic for a newbie tool.
> >>
> >> This could be an autoloadable function, not pasted verbatim in .zshrc.
> >> Also disagree with -l here. You can use $options[login] or $- to see
> >> if you're in a login shell already and start same. Things like this we
> >> can't fix after users already copy this config. It should try to
> >> mostly be configuration, not helper functions that can have permanent
> >> flaws once installed.
> >
> > Sure, I can move it to an autoloadable function. That’s fine by me. I did
> > not come up with the -l, though. Earlier in the thread, Oliver & Bart didn’t
> > like using `exec zsh` and offered this instead. See
> > [48031](https://www.zsh.org/mla/workers/2021/msg00244.html). I’d be happy to
> > change it, but I don’t know how they feel about it.
>
> You could also just have a comment saying something to the effect of
> "changes to this file will only take effect in new shells, you can
> either open a new terminal or type "zsh" in an existing terminal". I
> guess I don't care too much either way after all.
<...>
> >>> # Auto-save last 20 dirs to file whenever we change dirs.
> >>> # See
> >>> http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Recent-Directories
> >>> autoload -Uz add-zsh-hook chpwd_recent_dirs
> >>> add-zsh-hook chpwd chpwd_recent_dirs
> >>> zstyle ':chpwd:*' recent-dirs-file ${ZDOTDIR:-$HOME}/.chpwd-recent-dirs
> >>>
> >>> # On startup, initialize dir stack from file.
> >>> autoload -Uz chpwd_recent_filehandler
> >>> chpwd_recent_filehandler
> >>> cd $reply[1]
> >>> dirs $reply[@] >/dev/null
> >>
> >> Does this start zsh in some other directory than it inherited from the
> >> terminal? If so, nak from me on that, way too surprising.
> >
> > It makes the shell pick up in the same dir as where you left off last time.
> > I would hardly call that surprising. In fact, I would pretty much call that
> > _expected_ for most applications nowadays.
>
> I think most people on the list will strongly disagree with you here.
Oh yes. When I was giving my (mostly positive or indifferent) feedback
to Marlon privately on his request, I just ignored this part about
dirstack at all, since I neither use it nor care about it.
Making the shell chdir to a different directory every time is incredibly
unintuitive to most Unix shell users.
The runtime state restore functionality expected from applications does not
apply here at all, because the shell is not an application, but a power
tool.
To expand on this: while a running application is usually a
singleton in a given system, it's not uncommon for people to run about
10-15 fully independent shells for different tasks simultaneously.
Consider the user logs out from such a session and then logs back in —
the next shell they start will chdir to a directory last changed to by
those 15 shells, and that directory is hard to keep track of.
Attachment:
signature.asc
Description: PGP signature