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

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

e8058a8c8d77bb2b1940658eec3cbd809603fcb7

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

About this issue

Original URL
State: open
Created 3 years ago
Comments: 19 (14 by maintainers)

Most upvoted comments

@vladdoster As far as my understanding here goes, https://github.com/zdharma-continuum/zinit/pull/241 should have fixed this.

jankatins on Oct 30, 2022

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 on Apr 7, 2022

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 😉

pschmitt on Dec 6, 2021

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)

OrbitalHustler on Dec 6, 2021