home
home copied to clipboard
Specify explicit shim creation behaviors when defaults are not sufficient
If you install a GUI app with Chocolatey, it generates a GUI shim as expected. Running this GUI shim executable from a cmd.exe or powershell.exe results in the shim running without a parent process.
Example:-
- Run putty.exe directly from CLI and it runs with cmd.exe as it's parent
- Run putty.exe shim from the CLI and it runs without a parent
For normal apps, this isn't an issue but for my proxy server which uses AttachConsole() to write to the console (if invoked from one), it doesn't work since it cannot find it's parent console.
Opening this issue since you'd expect the shim to run as a child process just like the application it is shimming.
┆Issue is synchronized with this Gitlab issue by Unito
I just updated the original issue - I don't think this is a shimgen issue as noted in the other thread.
I will appreciate it if you had any comments on the following:-
- How to create a shim with wait for exit always set during installation
- Can a GUI shim with wait for exit run as a GUI app (without a console popup)
Thanks in advance.
CLI shims always wait for exit, GUI shims always exit immediately. However if you need it to do something else, you could call --shimgen-help
to learn of your options.
As in putty --shimgen-help
A full list of arguments you can call are at https://github.com/chocolatey/shimgen#shim-arguments as well
Thank you for your input.
We should probably leave this open as an enhancement until there is a way to create the shim in this way instead of a runtime call.
The only sensible way to implement this would be to run a GUI app with wait for exit automatically set if it was run from a console. That way, even though both the app and the shim both run in the background, there's still a process hierarchy for apps like Px to look for a parent console and attach to it if desired.
The only sensible way to implement this would be to run a GUI app with wait for exit automatically set if it was run from a console.
@genotrance for your particular case that might be true. However for most folks they don't want to have a console that is blocked. If they are using it to open something like gitk or something they might have open for a long time, if it blocks on the console, then they are unable to use the console until close the GUI app.
And for your particular use case, we should support a way of specifying options for the shim that is generated when the defaults are not what you want.
The defaults for shims have about 5+ years behind them and quite a bit of software. There are only a handful of edge cases that we've run into.
I agree you need to be careful on how you proceed but I'm not saying that the shim should hold onto the console - that would make it into a console app.
Assuming you make a GUI shim for a GUI app, what I'm asking for is the GUI shim to wait for the GUI app to exit if the GUI shim was invoked from a console. That way, the process hierarchy is maintained and the GUI app is free to attach to the parent console if required. The GUI shim would still run in the background and not hold onto the console, or block it.
I also agree that this is an edge case and you don't need to do it for every app but make it configurable.
Based on some changes happening to the Chocolatey repositories, this issue has been moved from the chocolatey/shimgen repository to the chocolatey/home repository.
+1, running into a similar issue with Twinkle Tray.
When launched as a first instance, this starts the GUI and prints debug messages to the parent console if it's available. A second instance supports a command-line interface. Because shimgen
creates a GUI shim, this requires users to pass --shimgen-waitforexit
for any console output to be shown.
It would be nice to have an option to configure default wait-for-exit behavior when a parent console is available, or at least have a way to opt out of GUI shim creation if undesired.