[BUG]: Autohotkey.exe cannot be found #371

Closed
opened 2026-01-05 14:50:05 +01:00 by adam · 2 comments
Owner

Originally created by @Haisaru on GitHub (May 10, 2024).

Running korombic.exe start --ahk does not find autohotkey v2. Results in Error: could not find autohotkey, please make sure it is installed before using the --ahk flag

Steps to reproduce the behavior:

  1. Install AutoHotkey V2
  2. Add C:\Users\User\AppData\Local\Programs\AutoHotkey\v2 to path
  3. Run korombic.exe start --ahk

For example:

OS Name:                   Microsoft Windows 10 Home
OS Version:                Build 19045.4291

It looks like, on line 1769 in komorebi/komorebic/src/main.rs let mut ahk: String = String::from("autohotkey.exe"); only checks for autohotkey.exe.

By default C:\Users\User\AppData\Local\Programs\AutoHotkey\v2 contains 3 files, AutoHotkey.chm, AutoHotkey32.exe, and AutoHotkey64.exe

Renaming AutoHotkey64.exe -> AutoHotkey.exe seems to fix things for me.

Originally created by @Haisaru on GitHub (May 10, 2024). Running korombic.exe start --ahk does not find autohotkey v2. Results in `Error: could not find autohotkey, please make sure it is installed before using the --ahk flag` Steps to reproduce the behavior: 1. Install AutoHotkey V2 2. Add `C:\Users\User\AppData\Local\Programs\AutoHotkey\v2` to path 3. Run korombic.exe start --ahk For example: ``` OS Name: Microsoft Windows 10 Home OS Version: Build 19045.4291 ``` It looks like, on line 1769 in `komorebi/komorebic/src/main.rs` `let mut ahk: String = String::from("autohotkey.exe");` only checks for autohotkey.exe. By default C:\Users\User\AppData\Local\Programs\AutoHotkey\v2 contains 3 files, AutoHotkey.chm, AutoHotkey32.exe, and AutoHotkey64.exe Renaming AutoHotkey64.exe -> AutoHotkey.exe seems to fix things for me.
adam added the bug label 2026-01-05 14:50:05 +01:00
adam closed this issue 2026-01-05 14:50:05 +01:00
Author
Owner

@LGUG2Z commented on GitHub (May 10, 2024):

Please use the KOMOREBI_AHK_EXE environment variable to set the executable name for whichever binary gets created with your AHK installation method.

As far as this project is concerned, what you and other users are experiencing here is an AHK packaging bug; the AHK project needs to decide on a single binary naming convention for installations of AHK via all methods (scoop, winget, msi, whatever it is).

We're not going to add lines and lines of codes to komorebic to handle N numbers of different possible AHK executable names.

@LGUG2Z commented on GitHub (May 10, 2024): Please use the `KOMOREBI_AHK_EXE` environment variable to set the executable name for whichever binary gets created with your AHK installation method. As far as this project is concerned, what you and other users are experiencing here is an AHK packaging bug; the AHK project needs to decide on a single binary naming convention for installations of AHK via all methods (scoop, winget, msi, whatever it is). We're not going to add lines and lines of codes to `komorebic` to handle N numbers of different possible AHK executable names.
Author
Owner

@LGUG2Z commented on GitHub (May 10, 2024):

https://lgug2z.github.io/komorebi/troubleshooting.html#autohotkey-executable-not-found added to the docs here

@LGUG2Z commented on GitHub (May 10, 2024): https://lgug2z.github.io/komorebi/troubleshooting.html#autohotkey-executable-not-found added to the docs here
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#371