Skip to content

fix(install): treat non-archive single file gracefully in ziextract.#787

Open
vladdoster wants to merge 2 commits into
mainfrom
fix/ziextract-install
Open

fix(install): treat non-archive single file gracefully in ziextract.#787
vladdoster wants to merge 2 commits into
mainfrom
fix/ziextract-install

Conversation

@vladdoster

@vladdoster vladdoster commented Jul 2, 2026

Copy link
Copy Markdown
Member

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 1334994 (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.

Before

Screenshot 2026-07-02 at 06 41 11

After

Screenshot 2026-07-02 at 06 41 23

How Has This Been Tested?

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.

Types of changes

  • Breaking change (fix or feature that would cause existing functionality to change)
  • Bug fix (non-breaking change which fixes an issue)
  • Documentation change
  • New feature (non-breaking change which adds functionality)

Checklist:

  • All new and existing tests passed.
  • I have added tests to cover my changes.
  • I have updated the documentation accordingly.

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 1334994 (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>
@vladdoster

Copy link
Copy Markdown
Member Author

@pschmitt, any objections to merging this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant