windows cmd gvim.exe shim waits for subprocess

[SimplyKnownAsG]

I am using scoop in a windows cmd (perhaps why i am the only person seeing this). The gvim.exe shim waits for the subprocess to terminate, and this is not desirable. The gvim.ps1 shim works just fine: running gvim opens a new windows and a new prompt is available.

I'm not sure how the gvim.exe shim is created but it would be nice if it did something equivalent to start / b ..\path\to\current\gvim.exe $*.

I'm happy to provide any additional information, though I'm not sure what may be needed or how to get it ;-). I'm sure there is a way to make .ps1 files executable from windows cmd, but regardless gvim.exe from powershell exhibits the same undesired behavior.

[stkb]

This is because of #1606: the shim executable is a console app and waits for the windowed app it calls to exit before returning. I'd like to see it fixed too and maybe I'll look at it next.

However even if that were fixed, there's still a problem with Vim. The Windows gvim.exe file doesn't support the --nofork flag, so you can't wait for it at the console if you do want to run it that way.

As I understand it, with the normal Vim installation, it's recommended to use the gVim.bat file created in the c:\Windows(!) directory, which looks for the --nofork flag and calls start gvim.exe with or without the /wait argument as necessary.

We can create this file in put it in the app dir during the installation, and shim gvim.exe to it instead of the original gvim.exe. I've just tested it and will create a PR for it.

[SimplyKnownAsG]

if it work's I'll be happy, but is there a benefit of having an .exe call a .bat call a .exe? Could the shim just be the .bat file? maybe that is lower-level than this specific package.

Thanks for looking into it!

[stkb]

Yeah as it turns out, the shim is actually a .cmd file (and a .ps1 for PowerShell).

That leaves nothing for bash, but that's a problem for another day...

Have tested it: gvim on the command line doesn't wait; with --nofork or -f flags it does.

[SimplyKnownAsG]

very neat. is there a way for me to test it as well? (really I'm just curious how I would test making a package myself)

[stkb]

For creating/testing your own packages, others might say to create your own bucket, though I prefer to create them directly in the working copies (installations) of the scoop or scoop-extras repos.

To pull the changes from this PR into your own scoop installation, go the ~/scoop/apps/scoop/current folder (it's a git repo), then:

git fetch https://github.com/lukesampson/scoop pull/2012/head:gvim-shim

This pulls the change into a gvim-shim branch. To put the change on master:

git cherry-pick gvim-shim

If that doesn't work for you, you can just copy the raw contents of the updated vim.json and paste it into ~/scoop/apps/scoop/current/bucket/vim.json .

(Oh, I nearly forgot, I've been assuming all along you're using the vim package, not the gvim one (which I noticed later). The Vim package also contains gVim, so I'm not sure what the difference is.)

You can make any changes you like to the scoop source or app manifests in the scoop/current or buckets/extras folders and scoop will still work and use those changes. However, if you don't commit the changes, then updating either scoop or the extras bucket will fail, so you won't get the lastest changes pulled in. If you commit your changes they are kept though.

If you really mess up in either repo then git reset --hard remotes/origin/master should set everything back to normal.

[chawyehsu]

You guys could just:

scoop install https://raw.githubusercontent.com/stkb/scoop/388db6e7ce2fb82b219e6a8bc2e036ef0fdea2a4/bucket/vim.json

[stkb]

I forgot you could install from an url :) The reason I don't use that though, while it's good for a quick test, is that you don't get further updates for that app. You have to remember to uninstall it and then re-install from the main bucket again after the PR has been merged.

[SimplyKnownAsG]

thanks for the tips, very helpful! I realize some of that is fairly well documented, except if there is a way to have scoop reset --hard origin/master itself. It is odd to me that I can't actually use scoop bucket add stkb https://github.com/stkb/scoop.git because the scoop repo itself isn't a bucket.

Anyway, your changes worked great for me. I look forward to them being merged :-)

[stkb]

Yeah the scoop repo isn't a bucket, and the main bucket isn't a repo (it's in the /bucket folder of the scoop repo), so that won't work I think.

I don't think there's a way to have scoop reset itself, but the git command should work fine.

[rasa]

This issue should be fixed in #3998, which was merged into master. To use, type:

scoop config shim kiennq
scoop reset *

or

scoop config shim 71
scoop reset *

Eventually, one of those shims (probably kiennq) will be made the default.

If this issue is still a problem after trying both solutions above, please reopen this issue. Thanks!