.zinit-download-file-stdout made every request anonymously and gave
up on the first transient error. The gh-r test suite alone exceeds
GitHub's anonymous API limit of 60 requests/hour/IP, and racing CI
runs trip per-IP abuse throttling, failing whole zunit slices (run
33138613456: 28 failures, all rate-limited downloads).
Send Authorization from GITHUB_TOKEN/GH_TOKEN, strictly limited to
api.github.com so tokens never reach asset CDNs, mirrors, or snippet
hosts, and retry transient HTTP errors in curl and wget.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
Drop the anonymous-function indirection in .zinit-cd-quiet and pass --,
collapse the duplicated landing cd in .zinit-restore-dir, and convert the
six remaining hand-rolled copies of the idiom in zinit-install.zsh to the
named helper.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
atclone evals inline, unlike the atpull hooks, which go through
.zinit-at-eval and get a function frame that absorbs a return from the
ice body. Wrap the eval so the restore runs on every path.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
The ___moved guard skipped the restore whenever zinit did not cd
itself, so an ice body that cds under nocd stranded the shell wherever
the plugin left it. Make the restore unconditional and give
.zinit-restore-dir a fast path so the case where nothing moved stays
free.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
∞zinit-configure-base-hook cd'd into the plugin directory inside a plain
{ } block -- not a subshell -- and every one of its four return paths
left the shell parked there. A `zinit update' on a plugin using the
configure ice moved the user's shell and never moved it back.
Wrap the block in an always clause so the directory is restored on all
paths, and use .zinit-cd-quiet instead of a bare `cd --', which was also
firing chpwd hooks and AUTO_PUSHD.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
Every ice that runs code inside a plugin or snippet directory (atinit,
atload, multisrc, atclone, atpull, ps-on-unload) saved and restored $PWD
around the temporary cd, but never $OLDPWD. `cd -q' suppresses chpwd
hooks and `noautopushd' suppresses the directory stack, but neither
suppresses $OLDPWD, so the cd back left it pointing at the directory
just visited. Opening a new shell and pressing `cd -' jumped into a
zinit plugin directory without the user ever having gone there.
Add .zinit-cd-quiet/.zinit-restore-dir, which return to the original
$PWD by cd'ing through the original $OLDPWD for real. A plain $OLDPWD
assignment is not enough: `cd -' reads zsh's internal previous-directory
state, not the parameter, so assigning it leaves the parameter looking
correct while `cd -' still navigates to the plugin directory. When the
original $OLDPWD is empty or has since been deleted, bounce through
$PWD instead, which degrades `cd -' to a harmless no-op rather than
emitting an error and leaking the plugin directory anyway.
Also gate the restore on the cd having actually happened. It ran
unconditionally, so with the nocd ice -- where no cd takes place -- the
no-op cd back to $PWD still set OLDPWD=$PWD, silently discarding the
user's real previous directory.
Sites already protected by a real subshell, and the user-facing `zinit
cd' and `zinit create' commands that are meant to leave you in the
target directory, are left untouched.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
Change `ziextract` when no extractor case matches and no explicit type was passed (-z $ext), file is treated as plain single file with info message
`'<file>' is not an archive — keeping it as a plain file.` plus chmod a+x. The existing exec-bit collection then picks it up, sets REPLY for --move, prints normal
success. Error message retained for explicit bogus types (ziextract file bogus-type). One iteration mid-verify: dropped -- from chmod — BSD/macOS chmod rejects it (chmod: --:
No such file or directory).
Why it broke: commit 1334994f (PR #771) made +x detection archive-exec-bit-only. Bare gh-r binaries arrive over HTTP with 644 and no extension => no extractor, no exec bit →
error branch. Pre-#771, file(1) detection covered this case.
Tests (tests/ices.zunit): two new — plain-file success path (asserts no error, message present, file executable) and bogus-explicit-type error
retention. Suite 16/16, including #771's ziextract-permissions. Regression-validated: plain-file test fails 15/16 with fix stashed.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
When using extract'!' with from'gh-r', ziextract was called twice:
1. First by the gh-r download code (line 407) — extracting the archive directly
2. Then by the ∞zinit-extract-hook — calling ziextract --auto --move
On the second call, the .tar.gz was already gone, so --auto mode fell through to file-command detection, which identified .jar files as zip archives
and tried to extract them — corrupting the plugin and producing errors.
Fix: Both the gh-r download path (line 407) and the tarball path (line 272) now skip their direct ziextract call when the extract ice is set,
deferring entirely to the ∞zinit-extract-hook which handles it correctly.
* Refactored 'configure' and 'make' ices
* New 'build' ice sets 'configure' and 'make ices if no flags are needed.
* New 'cmake' ice will build/install using 'cmake'
* Delete command now handles programs using 'make' and 'cmake' ices
* Setting `$ZINIT[DEBUG]` enables debug logging (i.e., `+zi-log "{dbg} message ..."`)
- Rename all instances of +zinit-message to +zi-log
- Maintain compatibility with community plugins/annexes by forwarding +zinit-message calls to +zi-log
Signed-off-by: Doster, Vladislav <mvdoster@gmail.com>
Zinit creates a directory named `._zinit` to store metadata. However, this
metadata should not be added to git.
Closes#395
Signed-off-by: wzy <32936898+Freed-Wu@users.noreply.github.com>
Co-authored-by: Vladislav Doster <mvdoster@gmail.com>
This reverts commit b979847bd4, reversing
changes made to da924a21a1.
I (@vladdoster) accidentally merged this into the wrong repository. Apologies for the lack of due diligence.
This can be used to overwrite `as'null'`, which would otherwise not trigger
completion detection and installation.
It will override the `nocompletions` ice when both are specified (e.g., using
the default ice annex).
