"--shimgen-usetargetworkingdirectory" as default argument

[cosmomill]

It would be very useful to create executables with --shimgen-usetargetworkingdirectory as default argument. Cause many so-called portable apps expecting the config file in the current working directory. E.g. the executable for Regshot in $env:ChocolateyInstall\bin\Regshot-x64-Unicode.exe can't find the regshot.ini if not executed in $env:ChocolateyInstall\lib\regshot\tools\. So you always have to run $env:ChocolateyInstall\bin\Regshot-x64-Unicode.exe --shimgen-usetargetworkingdirectory to start Regshot. The WOX launcher is another example which creates an image directory in the current working directory. It would be great to have these applications in the $PATH.

┆Issue is synchronized with this Gitlab issue by Unito

[ferventcoder]

While I appreciate that you believe this should be the default, let's talk a little more about how shimgen works so I can get an understanding of why.

• When a shim runs, it runs from the $env:ChocolateyInstall\bin path. The working directory for the shim is your current directory.
• The shim starts the binary it represents in the actual location it exists. The working directory is still the current directory you are in.
• Most executables are able to find everything surrounding the actual executable that must exist for it to work appropriately, including config files.

There are a few that are badly behaved executables that require that you are actually in the folder where they exist to run them. That literally means you can not have them in the PATH and execute them from anywhere on the system, you can only go to the directory where they are located and execute them from there. --use-targetworkingdirectory overcomes this issue allowing you to execute them from anywhere.

There are some GUI applications that are set to be run from the executable directory as the working directory in the start menu. I wonder if this is what you are running into?

I also wonder if it would make sense to be able to provide an option to a shim to have it always start with arguments you want it to?

And also a way to provide this option as part of creating shims for these badly behaved apps?

[cosmomill]

Thank you for your fast and detailed response.

There are some GUI applications that are set to be run from the executable directory as the working directory in the start menu. I wonder if this is what you are running into?

That's not the issue, I think it's uncommon to create shim's for "install" packages.

I also wonder if it would make sense to be able to provide an option to a shim to have it always start with arguments you want it to?

And also a way to provide this option as part of creating shims for these badly behaved apps?

I think one outstanding feature of Chocolatey is the possibility to have all executables in the PATH without polluting it. Furthermore Chocolatey automatically create these executables for packages in $env:ChocolateyInstall\lib\. I would like to have the option to create working shim's for these badly behaved executables. I think of an argument like --gui which sets --shimgen-gui as default argument for the resulting shim.

[ferventcoder]

I would like to have the option to create working shim's for these badly behaved executables. I think of an argument like --gui which sets --shimgen-gui as default argument for the resulting shim.

The 0.9.10 beta version of shimgen automatically determines it is a GUI and sets it appropriately without the need for a .gui file.

[ferventcoder]

I think one outstanding feature of Chocolatey is the possibility to have all executables in the PATH without polluting it.

I'm guessing you are saying this feature is great, not that it still needs this feature? If so, we think so as well.

[ferventcoder]

I would like to have the option to create working shim's for these badly behaved executables.

I agree.

[ferventcoder]

But I also like a consumer call to adjust the default behavior of a shim.

[cosmomill]

But I also like a consumer call to adjust the default behavior of a shim.

I can only serve you with a "Feature Request" 😉
Thanks for your time.

[gep13]

Based on some changes happening to the Chocolatey repositories, this issue has been moved from the chocolatey/shimgen repository to the chocolatey/home repository.