AutoHotkey Path Problem

By Xah Lee. Date:

This page documents some file path problems of AutoHotkey scripting language, and also some compexlity of computing.

Symptoms

Suppose you have a Windows shortcut file, named “ErgoEmacs 1.8.0.1”, at C:\Users\mary\Desktop\.

Now, create a file with this content:

Run "C:\Users\mary\Desktop\ErgoEmacs 1.8.0.1"

Name it for example “test.ahk”. Double click to run it. AutoHotkey will complain about file not found.

However, adding the “.lnk” extension works:

Run "C:\Users\mary\Desktop\ErgoEmacs 1.8.0.1.lnk" ; works

But, other files without extension also works, example:

Run "C:\Users\mary\Desktop\emacs 23.2.1 -Q" ; works

This is odd. Here's a summary of what works and not:

; shortcut file name: ErgoEmacs 1.8.0.1.lnk
 Run "C:\Users\mary\Desktop\ErgoEmacs 1.8.0.1.lnk" ; works

; shortcut file name: ErgoEmacs 1.8.0.1.lnk
 Run "C:\Users\mary\Desktop\ErgoEmacs 1.8.0.1" ; no

; shortcut file name: ErgoEmacs-1.8.0.1.exe - Shortcut.lnk
 Run "C:\Users\mary\Desktop\ErgoEmacs-1.8.0.1.exe - Shortcut" ; no

; shortcut file name: ErgoEmacs-1.8.0.1.exe - Shortcut.lnk
 Run "C:\Users\mary\Desktop\ErgoEmacs-1.8.0.1.exe - Shortcut.lnk" ; no

Apparently, the problem isn't just about having or not having the “.lnk” extension there. I think it might also have to do with the shortcut name having a version string with multiple dot chars. It seems to confuse ahk in its attempt to interpret the path.

Use Full Name with Extension For Windows Scripting

Not familiar with scripting on Windows, so i did a little test with PowerShell to see how it behaves. Here's a console log:

PS C:\Users\mary\Desktop> explorer.exe '.\ErgoEmacs 1.7.lnk'
PS C:\Users\mary\Desktop> explorer.exe '.\ErgoEmacs 1.8.0.1.lnk'
PS C:\Users\mary\Desktop> explorer.exe '.\emacs 23.2.1 -Q.lnk'
PS C:\Users\mary\Desktop> explorer.exe '.\ErgoEmacs-1.8.0.1.exe - Shortcut.lnk'

Shows that it all runs fine. So, the problem must be AutoHotkey.

When writing scripts on Windows, apparently the full file name with the “.lnk” extension is preferred. Also, apparently when calling executables, full name with “.exe” is preferred. I think so because: (1) when pressing the Tab key for name completion, full file name is suggested. (2) when using a file without the “.lnk” extension, PowerShell refuses to open it. (it'll open a default directory)

This seems obvious now. Full file name is also preferred when scripting in unix, even though sometimes file extension or program name be omitted (For example, the shebang #!). (In Emacs Lisp, whether the “.el” or “.elc” can be omitted is also non-trivial.)

AutoHotkey Problem

I think i narrowed down this problem into a clean example. Create a shortcut named like “ErgoEmacs-1.8.0.1.exe - Shortcut” in your personal desktop. Then, the following ahk script will fail:

Run "C:\Users\mary\Desktop\ErgoEmacs-1.8.0.1.exe - Shortcut.lnk"

The error is:

ahk shortcut path error

Apparently, ahk tried to parse the path into parameters, probably because it sees the “.exe” part.

“.lnk” Extension Does Not Show

Another complexity that's interesting to note here is that the “.lnk” file extension does not show in GUI window, even if you have folder options to show file extensions. Wikipedia explains:

Microsoft Windows uses .lnk as the filename extension for shortcuts to local files, and .URL for shortcuts to remote files, like web pages. Commonly referred to as “shortcuts” or “link files”, both are displayed with a curled arrow by default, and no filename extension. (The extension remains hidden in File Explorer even when “Hide extensions for known file types” is unchecked in File Type options, because it is controlled by the NeverShowExt option in HKEY_CLASSES_ROOT\lnkfile in the Registry. The IsShortcut option causes the arrow to be displayed.)

Desktop File Location Mirror

Another potential complexity is that, on Windows, there are 2 locations for Desktop files, and shortcut files showing in the public one will automatically be mirrored on the user one by some virtual mechanism. (but not the other way, of course)

See: Windows: Start Menu Folder Location

…

Overall, to understand the situation in depth, is to understand: