[vim/vim] Allow cmdlets (not just executables) as g:zip_unzipcmd (Issue #17987)

29 views
Skip to first unread message

Shay Hill

unread,
Aug 13, 2025, 1:51:19 PMAug 13
to vim/vim, Subscribed
ShayHill created an issue (vim/vim#17987)

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.

It is currently impossible to set Expand-Archive (Powershell internal unzip) as g:zip_unzipcmd because the "sanity checks" in zip.vim check that g:zip_unxipcmd is executable. Expand-Archive is not executable, because it is not an executable. Removing the "sanity checks" in zip.vim will allow users to set g:zip_unzipcmd = 'Expand-Archive' and then :e archive.zip.

Describe the solution you'd like

I would like for the sanity checks in zip.vim to be removed or for some other allowance to be made for cmdlets. I'd have submitted this as a pull request, but I am not sure how to run the tests in test_plugin_zip.vim to ensure I wasn't breaking anything.

Describe alternatives you've considered

A Powershell user can currently open an archive from the command line with vim archive.zip, presumably because nertw uses it's own zip, but not being able to open an archive from within Vim prevents plugins like habamax/vim-dir from opening archives for Powershell users.


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987@github.com>

Christian Brabandt

unread,
Aug 13, 2025, 4:29:17 PMAug 13
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#17987)

Hm, Can't we dynamically test that the cmdlet exists, if &shell =~ 'powershell\|pwshell' That way we wouldn't lose the checks


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987/3185638921@github.com>

Shay Hill

unread,
Aug 13, 2025, 5:04:48 PMAug 13
to vim/vim, Subscribed
ShayHill left a comment (vim/vim#17987)
For what it’s worth, that would still fail for zip programs that require a command. E.g., (from memory) `z7 -e`.

As a PowerShell user, I would experience a lot more flexibility if more commands were available as functions. That way argument order differences could be easily overcome. But that’s getting off topic.

On Aug 13, 2025, at 15:28, Christian Brabandt ***@***.***> wrote:


[https://avatars.githubusercontent.com/u/244927?s=20&v=4]chrisbra left a comment (vim/vim#17987)<https://github.com/vim/vim/issues/17987#issuecomment-3185638921>

Hm, Can't we dynamically test that the cmdlet exists, if &shell =~ 'powershell\|pwshell' That way we wouldn't lose the checks


Reply to this email directly, view it on GitHub<https://github.com/vim/vim/issues/17987#issuecomment-3185638921>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADAKIEZGGRYH22ZKHKIB7QD3NONXNAVCNFSM6AAAAACD2L2TTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOBVGYZTQOJSGE>.
You are receiving this because you authored the thread.Message ID: ***@***.***>


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987/3185813991@github.com>

Christian Brabandt

unread,
Aug 17, 2025, 3:40:17 PMAug 17
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#17987)

Yeah it seems the zip plugin hard-codes a few additional arguments, making it rely on a real zip and unzip command. It should probably use a g:zip_args and g:unzip_args variables for those


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987/3194608333@github.com>

Shay Hill

unread,
Aug 17, 2025, 11:26:53 PMAug 17
to vim/vim, Subscribed
ShayHill left a comment (vim/vim#17987)

All of that would be nice, but in this case, *something* file will work for anything I know of as long as *something* could be

  • an executable
  • an executable followed by a command
  • any one of (probably very few) [optionally] "allowlisted" cmdlets

Many applications of zip and unzip would be called explicitly, so any Vim function could be used. This call to unzip happens implicitly, so the only control you have as a user is to set g:zip_unzipcmd.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987/3194983996@github.com>

Christian Brabandt

unread,
Aug 18, 2025, 3:04:04 AMAug 18
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#17987)

I don't really want to relax the executable() restrictions however. Otherwise in case of an error I think it may not be entirely obvious why it is not working. Perhaps instead we could should hard-code the allowed value Expand-Archive ?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987/3195382094@github.com>

Shay Hill

unread,
Aug 18, 2025, 12:07:39 PMAug 18
to vim/vim, Subscribed
ShayHill left a comment (vim/vim#17987)

Not surprisingly, you were right, and I was wrong. Expand-Archive requires a dramatically different command (and does not have an equivalent to -Z1). I think I made some erroneous assumptions based on my not having a virgin PowerShell to test in. I'm going to keep playing with my zip.vim and raise this again if the required changes aren't too dramatic.

I`ll leave it to the maintainers to decide if this feature request should be closed, because there are plenty of PowerShell users out there, and this might me a more straightforward enhancement than I think.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987/3197540079@github.com>

Shay Hill

unread,
Aug 19, 2025, 8:50:03 AMAug 19
to vim/vim, Subscribed
ShayHill left a comment (vim/vim#17987)

Given the desire to preserve the executable checks, what I've come up with is

fun! UsePowerShellUnzip()
  return &shell =~ 'pwsh' && g:zip_unzipcmd == 'Expand-Archive'
endfun

fun! UnzipFound()
  return executable(substitute(g:zip_unzipcmd,'\s\+.*$','','')) || UsePowerShellUnzip()
endfun

fun! UnzipIsSafeExecutable()
  return dist#vim#IsSafeExecutable('zip', substitute(g:zip_unzipcmd,'\s\+.*$','','')) || UsePowerShellUnzip()
endfun

... where effectively, the combination of shell=pwsh and g:zip_unzipcmd = 'Expand-Archive' become a switch, telling vim.zip to use Powershell Core cmdlets instead of an executable.

I couldn't see a straightforward way of preserving the checks if g:zip_args and g:unzip_args were exposed for any user-defined function. You could still check the value of g:zip_unzipcmd, but then use anything in the user-defined function.

The only way forward (and I've implemented this for browse and read) is to explicitly branch within the functions:

  if UsePowerShell()
    exe 'keepj sil r! [System.IO.Compression.ZipFile]::OpenRead('
   \    . s:Escape(a:zipfile, 1)
   \    . ').Entries | ForEach-Object { $_.FullName }'
  else
    exe $"keepj sil r! {g:zip_unzipcmd} -Z1 -- {s:Escape(a:zipfile, 1)}"
  endif

I'm using this for myself, but if there's any interest in going forward in this manner, I'll implement zip as well, update the documentation, and submit a PR.

Note: I've so far only implemented unzip because a Windows PowerShell user who installs git bash (which I suppose most of us do) will have a zip that works with vim.zip. That's just convenience on my part, but happy to put that together for a pr.

Additional Note: vim.zip is built around what is straightforward to do in unzip. The commands are somewhat less straightforward in PowerShell Core. Still not bad, but I do not know how to expand a single file within an archive in deprecated PowerShell 5. I'm not even certain it's possible. I have only been able to support the more modern PowerShell Core.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17987/3200626494@github.com>

Christian Brabandt

unread,
Sep 22, 2025, 3:04:11 PMSep 22
to vim/vim, Subscribed

Closed #17987 as completed via 70d745a.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/17987/issue_event/19847686273@github.com>

Reply all
Reply to author
Forward
0 new messages