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.
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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.
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
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.
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.
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.
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.
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.![]()