[bug]: `mv` ice does not rename file on initial run

[OrbitalHustler]

Issue description

When starting zinit for the first time, using the direnv hook given in zinit wiki:

# Direnv hook into zsh
# https://zdharma.github.io/zinit/wiki/Direnv-explanation/
zinit from"gh-r" as"program" mv"direnv* -> direnv" \
    atclone'./direnv hook zsh > zhook.zsh' atpull'%atclone' \
    pick"direnv" src="zhook.zsh" for \
        direnv/direnv

The renaming (direnv* to direnv) does not happen:
ziextract: Successfully extracted and assigned +x chmod to the file: direnv.linux-amd64'.`

The file direnv.linux-amd64 isn't renamed to direnv.

If however I then rm -rf ~/.local/share/zinit/plugins/direnv---direnv and start zsh again, I get:

ziextract: Successfully extracted and assigned +x chmod to the file: direnv.linux-amd64'.
renamed 'direnv.linux-amd64' -> 'direnv'`

So it seems to only happen during the very first time zinit is setup.

zinit config

if [[ ! -f "$ZINIT_DIR/zinit.zsh" ]]; then
    echo -e "y" | sh -c "$(curl -fsSL https://git.io/zinit-install)"
fi

source "$ZINIT_DIR/zinit.zsh"
autoload -Uz _zinit
(( ${+_comps} )) && _comps[zinit]=_zinit

# Load a few important annexes, without Turbo
# (this is currently required for annexes)
zinit light-mode for \
    zdharma-continuum/z-a-rust \
    zdharma-continuum/z-a-as-monitor \
    zdharma-continuum/z-a-patch-dl \
    zdharma-continuum/z-a-bin-gem-node

### End of Zinit's installer chunk

zinit ice wait lucid
zinit snippet OMZ::plugins/colored-man-pages
zinit ice wait lucid
zinit snippet OMZ::plugins/colorize
zinit ice wait lucid
zinit snippet OMZ::plugins/command-not-found
zinit ice wait lucid
zinit snippet OMZ::plugins/copydir
zinit ice wait lucid
zinit snippet OMZ::plugins/copyfile
zinit ice wait lucid
zinit snippet OMZ::plugins/cp
zinit ice wait lucid
zinit snippet OMZ::plugins/debian
zinit ice wait lucid
zinit snippet OMZ::plugins/dircycle
zinit ice wait lucid
zinit snippet OMZ::plugins/extract
zinit ice wait lucid
zinit snippet OMZ::plugins/jump
zinit ice wait lucid
zinit snippet OMZ::plugins/mercurial
zinit ice wait lucid
zinit snippet OMZ::plugins/rsync
zinit ice wait lucid
zinit snippet OMZ::plugins/safe-paste

# # Bundles from external repos
zinit ice wait lucid
zinit load Tarrasch/zsh-bd
zinit ice wait lucid
zinit load djui/alias-tips
zinit ice wait lucid
zinit load hlissner/zsh-autopair
zinit ice wait lucid
zinit load mdumitru/fancy-ctrl-z
zinit ice wait lucid
zinit load rutchkiwi/copyzshell
zinit ice wait lucid
zinit load wfxr/forgit
zinit ice wait lucid
zinit load redxtech/zsh-show-path
# zinit load kutsan/zsh-system-clipboard
zinit ice wait lucid
zinit load zsh-users/zsh-completions

# Do not turbo mode (ice wait) these packages
zinit load jeffreytse/zsh-vi-mode # problems with fzf Ctrl+R, Ctrl+Z, Ctrl+T bindings if turbo
zinit ice svn pick"tmux.plugin.zsh"
zinit snippet OMZ::plugins/tmux
zinit load Aloxaf/fzf-tab
zinit snippet OMZ::plugins/fzf # after fzf-tab
zinit load davidde/git
zinit snippet OMZ::plugins/common-aliases # if turbo, replaces my aliases
unalias zi
zinit snippet OMZ::plugins/zoxide # so the function "zi" replaces the "zinit" alias "zi" properly

# Direnv hook into zsh
# https://zdharma.github.io/zinit/wiki/Direnv-explanation/
zinit from"gh-r" as"program" mv"direnv* -> direnv" \
    atclone'./direnv hook zsh > zhook.zsh' atpull'%atclone' \
    pick"direnv" src="zhook.zsh" for \
        direnv/direnv

# LS_COLORS managed by zinit
# https://zdharma.github.io/zinit/wiki/LS_COLORS-explanation/
#
zinit ice atclone"dircolors -b LS_COLORS > clrs.zsh" \
    atpull'%atclone' pick"clrs.zsh" nocompile'!' \
    atload'zstyle ":completion:*" list-colors “${(s.:.)LS_COLORS}”'
zinit light trapd00r/LS_COLORS

# # # Order important
zinit ice wait"1" lucid
zinit load zsh-users/zsh-syntax-highlighting # last

zicompinit; zicdreplay

# # # Theme
zinit ice depth="1"
zinit load romkatv/powerlevel10k

zinit version or commit ID

e8058a8

zsh version

5.8

host info

OSTYPE=linux-gnu CPUTYPE=x86_64 MACHTYPE=x86_64 5.10.60.1-microsoft-standard-WSL2 VERSION="11 (bullseye)" ID=debian

[pschmitt]

Can you please share the output of setopt? I wonder if it may be an extendedglob kinda thing.

[OrbitalHustler]

setopt gives:

alwaystoend
autocd
nobeep
correct
extendedglob
extendedhistory
histexpiredupsfirst
histfindnodups
histignorealldups
histignoredups
histignorespace
histsavenodups
histverify
interactive
monitor
nonomatch
promptsubst
sharehistory
shinstdin
zle

[OrbitalHustler]

Actually that is setopt in the case where it works. When it doesn't work, it is

interactive
monitor
shinstdin
zle

I see that there is no extendedglob there, could that be the cause in your opinion?

How should it be fixed? Should the zinit user be expected to set it correctly before calling zinit?

[OrbitalHustler]

Actually, even if I call setopt extendedglob before calling the first zinit install/plugins update, the direnv renaming doesn't happen.

More details to help pin it down:

If I run rm ~/.local/share/zinit/plugins && exec zsh, zinit plugins get reinstalled and direnv mv is done correctly.

If I run rm ~/.local/share/zinit/ && exec zsh, then zinit & its plugins get reinstalled and the direnv mv isn't done correctly (the bug happens)

[pschmitt]

How should it be fixed? Should the zinit user be expected to set it correctly before calling zinit?

No user-config should be mandatory, it's zinit's job to set zsh opts in the functions where it's behavior depends on the value of those. We will fix this in zinit ;)

[jankatins]

In #199 I had some fun trying to figure out why mv/atclone/... are not run after I deleted the whole `~/.zinit/plugins/* dir and I found one codepath which resulted in no hooks getting registered, effectively not running any ices:

When zinit.zsh is sourced, one of the last things is actually checking and ensuring that the plugins dir is correctly initialized (recreating it if not) and then afterwards registering all the ice hooks. An xtrace revealed that the registering never happens when I delete my plugin dir. Following the last call in the source zinit.zsh line, it's basically .zinit-prepare-home (zinit.zsh#L3055) -> rebuilds the plugin dir and in the last line of that block calls .zinit-compinit &>/dev/null (zinit.zsh#L1207-L1219) -> .zinit-compinit does as a first thing check something in OPTS (zinit-install.zsh#L611-L612) but this fails with the following error when I remove the redirect to dev null:

+.zinit-compinit:2> [[.zinit-compinit:2: bad math expression: operand expected at `/Users/jan...'
 -n '' ]]

The redirect to dev null hides the error but the error still results in not finishing the sourcing of the zinit.zsh file, so the hooks are not registered.

I did the following change and it seems to fix the problem but to be honest I do not understand that code at all so I do not know what side effects this might have:

--- a/zinit-install.zsh
+++ b/zinit-install.zsh
@@ -609,7 +609,7 @@ builtin source "${ZINIT[BIN_DIR]}/zinit-side.zsh" || {
 #
 # No arguments.
 .zinit-compinit() {
-    [[ -n ${OPTS[opt_-p,--parallel]} && $1 != 1 ]] && return
+    [[ -n $OPTS && -n ${OPTS[opt_-p,--parallel]} && $1 != 1 ]] && return

     emulate -LR zsh
     builtin setopt nullglob extendedglob warncreateglobal typesetsilent

Maybe interesting for @percee to try out?

[jankatins]

I opened #241 for the above idea.

[OrbitalHustler]

@jankatins I'm currently redoing my config and I didn't add zinit back in yet. I'll try it when I get there tho. Thanks very much!

[vladdoster]

@percee

You shouldn't delete only the plugins directory, ever. If you want to delete plugins, run:

zinit delete --all

You break zinit when you delete the plugins directory since it holds _local---zinit

Regardless of the answer above, this brings up the issue of deleting zinit directories.
As I've said before @jankatins, this is not how you should delete plugins.

Use zinit delete --all
I would assume this edge-case is handled in the delete command since it deletes subdirectories and not the actual $ZINIT[PLUGINS_DIR] directory. So, is this needed or just not using the proper method of deleting plugins?

Link to my previous comment

Indeed, it avoids this issue altogether.

Originally posted by @vladdoster in #241 (comment)