With the text attribute set, core.autocrlf=false hands the decision to
core.eol, so a global core.eol=crlf still produces CRLF checkouts in the
sandbox clones.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
wait-invalid-suffix-x asserted on 'Expected one of: a, b, c', but
+zi-log colourises each suffix letter separately, so the raw output
carries escape sequences between them and no such contiguous substring
exists. Strip the escapes before asserting on the sentence.
for-invalid-as asserted rc 0 while the load ran on to
∞zinit-compile-plugin-hook, which returns 1 for this fixture ("No files
for compilation found") and made `zinit for' exit 1 for a reason
unrelated to the invalid ice under test. Add nocompile so the test
measures ice validation only.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
@setup bodies run under ERR_EXIT. Sourcing zinit.zsh trips it partway
through, so the setup aborted and zunit reported both tests as failures
with an empty message -- which read as a broken assertion rather than a
broken fixture. The source was redundant anyway: the bootstrap already
sources zinit from the sandbox clone.
Drop the ZINIT[BIN_DIR]="$PWD" override with it. It aimed the tests at
the real checkout instead of the sandbox, the same misdirection that
lets a failed bootstrap write into the working tree. Neither test calls
a zinit function; only the hook registries are needed.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
Covers atload, atinit and multisrc, the nocd branch, a since-deleted
$OLDPWD, an $OLDPWD that started unset, and the configure hook.
Each test asserts where `cd -' actually lands, not just the value of
$OLDPWD: `cd -' reads zsh's internal previous-directory state, so a
parameter-only assertion passes against a fix that merely assigns
$OLDPWD while leaving the bug in place. All seven fail without the
preceding two commits.
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>
- Check out zdharma-continuum/zunit at feat/run-tests-in-parallel-support and
run the gh-r and plugins suites with --slice
- Pin Homebrew/actions/setup-homebrew to a commit SHA and enable its sandbox
- Drop ncurses from the brew install list, relink it explicitly, and add
jemalloc; set HOMEBREW_NO_REQUIRE_TAP_TRUST
- Expand the OS matrix to "${os}-latest" and label jobs as "<test> | <os>"
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
Resolve ZINIT[...] settings from `zstyle ':zinit:config' <attr>` before
the BIN_DIR/HOME_DIR/derived-dir logic runs. The attribute name is the
hash field lowercased with `_` replaced by `-` (HOME_DIR -> home-dir).
An explicitly-set ZINIT[KEY] always wins over zstyle, which wins over
the built-in default; fully backward-compatible.
Signed-off-by: Vladislav Doster <mvdoster@gmail.com>
replicate/cog stopped shipping a static binary in its GitHub releases
(switched to a Python wheel coglet-*.whl as of v0.20.0), which broke the
linux gh-r CI job — ziextract cannot unpack a .whl, and the linked symlink
returns 'exec format error' when run.
Replace with sigstore/cosign, which still ships static binaries
(cosign-linux-amd64 / cosign-darwin-{amd64,arm64}) and slots into
the alphabetical position between 'checkmake' and 'compress'.
- Fix incorrect double extraction when `extract` ice is used with `from'gh-r'`
- Improved documentation of `extract` ice
- Added test units for `extract` ice
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.
