search

chocolatey / home

The place to start for issues with areas of Chocolatey that are infrastructure related, or really any issues could be started here. There is also choco for the CLI client, Chocolatey GUI for the GUI.
Apache License 2.0
29 stars 10 forks source link

Must choose between a cmd window or accurate %errorlevel% when using shim #124

Open teknowledgist opened 6 years ago

teknowledgist commented 6 years ago

I'm not sure this is a bug, but it is an undesired (and maybe unavoidable) result...

I am working on a couple packages (fastcopy.*) that need to use AutoHotKey. I could not get the exitcode the AHK script was supposed to return. It turns out, the actual AutoHotKey would return the exitcode (viewed as $process.exitcode or %errorlevel%), but I was having problems because I was simply calling "AutoHotKey" and relying on the path that included the shim (in Chocolatey\bin).

For example, a sample AHK script:

SetTimer, TooLong, 5000

msgbox, Testing!
ExitApp

TooLong:
ExitApp, 666

Doing this:

$Proc = start-process -filepath 'c:\programdata\chocolatey\lib\autohotkey.portable\tools\autohotkey.exe -argumentlist $AHKfilePath -passthru

causes Write-Host $proc.exitcode to return a "0" if the message box was clicked and "666" if it was left to close on it's own after 5 seconds. That is the expected behavior.

However, using the shim (which is on the path, but not necessarily the first instance of "autohotkey" encountered in the path) like so:

$Proc = start-process -filepath autohotkey -argumentlist $AHKfilePath -passthru

Will always return "0" and do so before the script is finished. (I.E. it is returning the successful start of the script.)

If I adjust for the shim:

$Proc = start-process -filepath autohotkey -argumentlist $AHKfilePath,'--shimgen-waitforexit' -passthru

I get a black, cmd window until the script exits, but I do get the correct exitcode.

I can't seem to find a way to get the AutoHotKey shim to run a "clean/hidden" script AND return the exitcode.

Of course, there is an argument to be made that the full AutoHotKey path should be used, but part of the purpose of shims is to avoid tracking down the full path, and AHK users may not realize their calls for autohotkey are passing through a shim that is "breaking" the expected behavior. Heck, it took me a few hours and a post to the AHK forums to identify the issue!

As I said, maybe this cannot be fixed, but I thought it should be pointed out as a "deficiency" for the record.

I still have much gratitude for the excellent work you do, so thank you.

┆Issue is synchronized with this Gitlab issue by Unito

gep13 commented 2 years ago

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