fix: trust archive permissions instead of file(1) heuristics in ziextract

[alberti42]

Problem

This PR fixes a bug in ziextract, the function responsible for unpacking archives
when installing plugins via from'gh-r' or any tarball download.

The original developer added a well-intentioned feature: after extracting an archive,
zinit would automatically detect which files are executables and set the +x permission
on them, so the user would not have to do it manually. To detect executables, the code
used the standard Unix utility file(1), which can inspect file contents and report
what kind of file each one is.

The problem is that file(1) does not actually tell you whether a file should be
executable. It tells you what kind of content a file contains. In practice, file(1)
labels any file containing common Python syntax — including documentation files, Vim
scripts, and test data — as "Python script text executable". Zinit's code then sees
the word "executable" in that output and dutifully applies chmod +x to all of them,
including files that have no business being executable at all.

Reproduction — install Neovim from its GitHub nightly release:

zinit lucid as'null' from'gh-r' for @neovim/neovim

The archive contains exactly 9 files with the execute bit set (bin/nvim,
lib/nvim/parser/*.so, share/nvim/runtime/scripts/less.sh). After installation,
fd -t=x reveals that many additional files have been marked executable:

bin/nvim
lib/nvim/parser/c.so
lib/nvim/parser/lua.so
lib/nvim/parser/markdown.so
lib/nvim/parser/markdown_inline.so
lib/nvim/parser/query.so
lib/nvim/parser/vim.so
lib/nvim/parser/vimdoc.so
share/nvim/runtime/autoload/python3complete.vim
share/nvim/runtime/autoload/pythoncomplete.vim
share/nvim/runtime/doc/if_pyth.txt
share/nvim/runtime/doc/remote_plugin.txt
share/nvim/runtime/indent/testdir/bash.in
share/nvim/runtime/indent/testdir/bash.ok
share/nvim/runtime/indent/testdir/bitbake.in
share/nvim/runtime/indent/testdir/bitbake.ok
share/nvim/runtime/scripts/less.sh

Root Cause

The file(1) magic database emits "Python script text executable" for any file
whose content matches common Python syntax patterns — import, class, def,
try/except — regardless of shebangs or filesystem permissions. A Vim documentation
file (if_pyth.txt) that merely documents the Python interface is enough to trigger it:

$ file share/nvim/runtime/doc/if_pyth.txt
share/nvim/runtime/doc/if_pyth.txt: Python script text executable, ASCII text

The word "executable" in file(1) output means "this is a file written in a
language that can be run" — not "this file should have the execute permission bit".
Zinit's filter was asking the wrong question. To make matters worse, file(1) applies
this label even to Python files with no shebang line — files that the kernel would
refuse to execute directly anyway, since there is no interpreter specified.

Fix

Replace the file(1)-based detection with a single glob that collects only files
whose execute bit is already set in the archive:

execs=( **/*~(._zinit(|/*)|.git(|/*)|.svn(|/*)|.hg(|/*)|._backup(|/*))(DN-*.) )
# Glob qualifier legend:
#   (DN-.)  — D=include dotfiles, N=null glob, -=no symlinks, .=regular files
#   (DN-*.) — same plus *=has execute bit set

This is the authoritative signal: if the package author wanted a file executable, they
set +x when creating the archive. Any file that lacks +x in the archive — library
module, documentation, data file — should stay non-executable regardless of its
content. If a plugin or app is packaged with wrong permissions — rare but possible —
the best course of action is for the user to correct them via atclone/atpull,
rather than having zinit apply heuristics that will assign wrong permissions far more
often than they fix anything.

Discussion: shebang-based detection

An alternative considered during this fix is to additionally mark executable any file
that has a shebang (#!) but was not +x in the archive — to compensate for packages
that forget to set permissions. Eventually, this was deliberately left out for two reasons:

1. A shebang does not reliably indicate that a file should be +x. The
   #!/hint/zsh pattern, common in the zinit ecosystem, is used purely as an editor
   syntax hint and is explicitly not meant to make a file executable.
2. If a plugin or app is packaged with wrong permissions — rare but possible — the
   best course of action is for the user to correct them via atclone/atpull,
   rather than having zinit apply heuristics that will assign wrong permissions far
   more often than they fix anything.

Feedback on this decision is welcome.

[github-actions]

🎉 This PR is included in version 3.15.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀