This page documents some file path problems of AutoHotkey scripting language, and also some compexlity of computing.
Suppose you have a Windows shortcut file, named “ErgoEmacs 184.108.40.206”, at 〔C:\Users\mary\Desktop\〕.
Now, create a file with this content:
Run "C:\Users\mary\Desktop\ErgoEmacs 220.127.116.11"
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 18.104.22.168.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 22.214.171.124.lnk Run "C:\Users\mary\Desktop\ErgoEmacs 126.96.36.199.lnk" ; works ; shortcut file name: ErgoEmacs 188.8.131.52.lnk Run "C:\Users\mary\Desktop\ErgoEmacs 184.108.40.206" ; no ; shortcut file name: ErgoEmacs-220.127.116.11.exe - Shortcut.lnk Run "C:\Users\mary\Desktop\ErgoEmacs-18.104.22.168.exe - Shortcut" ; no ; shortcut file name: ErgoEmacs-22.214.171.124.exe - Shortcut.lnk Run "C:\Users\mary\Desktop\ErgoEmacs-126.96.36.199.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.
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 188.8.131.52.lnk' PS C:\Users\mary\Desktop> explorer.exe '.\emacs 23.2.1 -Q.lnk' PS C:\Users\mary\Desktop> explorer.exe '.\ErgoEmacs-184.108.40.206.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: ① when pressing the Tab ↹ key for name completion, full file name is suggested. ② 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 (⁖ the shebang #!). (In Emacs Lisp, whether the “.el” or “.elc” can be omitted is also non-trivial.)
I think i narrowed down this problem into a clean example. Create a shortcut named like “ErgoEmacs-220.127.116.11.exe - Shortcut” in your personal desktop. Then, the following ahk script will fail:
Run "C:\Users\mary\Desktop\ErgoEmacs-18.104.22.168.exe - Shortcut.lnk"
The error is:
Apparently, ahk tried to parse the path into parameters, probably because it sees the “.exe” part.
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 Windows 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.)
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, Desktop, Quick Launch, File Locations
Overall, to understand the situation in depth, is to understand: