As a large humanitarian medical organisation, we have thousands of remote Windows 10 workstations to manage in many (overseas) countries, sometimes in very challenging contexts (remote parts of unstable developing countries with very poor Internet connections), and we need practical yet robust yet open-source/free solutions ... and AutoHotkey is surely one of them!
Many thanks to all involved developers for the outstanding work.
I have not found yet in this forum nor on the Web any reference to this possible bug/regression only affecting the latest stable AutoHotkey version 1.1.33.10 - previous stable version 1.1.33.09 does not look affected.
Here is a simple script that can already reveal the problem:
Code: Select all
#Warn All, StdOut ;; Enable warnings to assist with detecting common errors
#NoEnv ;; Avoids checking empty variables to see if they are environment variables (recommended for all new scripts)
;#Persistent ;; Keeps a script permanently running (that is, until the user closes it or ExitApp is encountered)
#SingleInstance Ignore ;; i.e. attempts to re-launch an already-running script are ignored (use AHK command-line option "/force" to launch unconditionally)
#NoTrayIcon ;; Disables the showing of a tray icon (will be enabled later if the script is not running in silent mode)
;#ErrorStdOut ;; N.B.: rather use standard AHK command-line switch "/ErrorStdOut"
;; N.B.: To redirect the script's both stdout and stderr streams to a file and also get the script exit code : << "%ComSpec%" /c " "myscript.exe" /ErrorStdOut > "myscript.log" 2>&1 " >>
;SetWorkingDir %A_ScriptDir% ;; N.B.: may be used to ensure a consistent starting directory but not wanted with such scripts to forcibly change the current working directory
SendMode Input ;; Recommended for new scripts due to its superior speed and reliability
Menu, Tray, Icon, , , 1 ;; Freeze the system tray icon (not changing e.g. when disabling hotkeys)
Suspend, On ;; Disables all hotkeys and hotstrings (not used with such scripts)
SetRegView 64 ;; Sets the registry view (used by RegRead, RegWrite, RegDelete and registry loops) to view the registry as a 64-bit application would (so both 32-bit and 64-bit registry can be accessed at once, e.g. both key trees under "HKLM\Software\" and "HKLM\Software\WOW6432Node\")
;SetBatchLines, -1 ;; Never sleep (i.e. have the script run at maximum speed).
vErrorLevel := ""
vLastError := ""
vLastException := ""
try
{
FileInstall, FileInstall\_ReadMe_01.txt, %A_ScriptDir%\_ReadMe_01.txt, 1
vErrorLevel := ErrorLevel
vLastError := A_LastError
}
catch e
{
vLastException := e
vErrorLevel := ErrorLevel
vLastError := A_LastError
}
FileAppend, % ( "vErrorLevel: " vErrorLevel " | vLastError: " vLastError " | vLastException: " vLastException "`r`n" ), *
;; EOF
A dummy non-empty ReadMe text file "FileInstall\_ReadMe_01.txt" should be created (so in a sub-folder ".\FileInstall\" relative to the AHK script "FileInstall01.ahk"), e.g. with contents:
Code: Select all
Fake ReadMe file
___
And here is a Command Prompt session demonstrating the problem (suggesting other people to check as well):
Code: Select all
> ver
Microsoft Windows [Version 10.0.18363.1916]
> %ComSpec% /a/e:on/v:on/f:off/d/c " @for %A in ( "1.1.33.09" "1.1.33.10" ) do @for %B in ( "Ahk2Exe-FileInstall01.ahk_%~A.log" ) do ( ( "AutoHotkey_%~A\Compiler\Ahk2Exe.exe" /bin "AutoHotkey_%~A\Compiler\ANSI 32-bit.bin" /in "FileInstall01.ahk" /out "FileInstall01.ahk_%~A.exe" & echo ERRORLEVEL:"!ERRORLEVEL!" ) > "%~B" 2>&1 & @type "%~B" ) "
> (("AutoHotkey_1.1.33.09\Compiler\Ahk2Exe.exe" /bin "AutoHotkey_1.1.33.09\Compiler\ANSI 32-bit.bin" /in "FileInstall01.ahk" /out "FileInstall01.ahk_1.1.33.09.exe" & echo ERRORLEVEL:"!ERRORLEVEL!" ) 1>"Ahk2Exe-FileInstall01.ahk_1.1.33.09.log" 2>&1 & )
Successfully compiled: FileInstall01.ahk_1.1.33.09.exe
ERRORLEVEL:"0"
> (("AutoHotkey_1.1.33.10\Compiler\Ahk2Exe.exe" /bin "AutoHotkey_1.1.33.10\Compiler\ANSI 32-bit.bin" /in "FileInstall01.ahk" /out "FileInstall01.ahk_1.1.33.10.exe" & echo ERRORLEVEL:"!ERRORLEVEL!" ) 1>"Ahk2Exe-FileInstall01.ahk_1.1.33.10.log" 2>&1 & )
Successfully compiled as:
C:\Tmp\AHK\FileInstall01.ahk_1.1.33.10.exe
ERRORLEVEL:"0"
> %ComSpec% /a/e:on/v:on/f:off/d/c " @for %A in ( "1.1.33.09" "1.1.33.10" ) do @for %B in ( "FileInstall01.ahk_%~A.exe.log" ) do ( call "FileInstall01.ahk_%~A.exe" > "%~B" 2>&1 & echo {{{ & type "%~B" & echo }}} & echo [[[ & type "_ReadMe_01.txt" & echo ]]] ) "
> (call "FileInstall01.ahk_1.1.33.09.exe" 1>"FileInstall01.ahk_1.1.33.09.exe.log" 2>&1 & echo {{{ & type "FileInstall01.ahk_1.1.33.09.exe.log" & echo }}} & echo [[[ & type "_ReadMe_01.txt" & echo ]]] )
{{{
vErrorLevel: 0 | vLastError: 0 | vLastException:
}}}
[[[
Fake ReadMe file
___
]]]
> (call "FileInstall01.ahk_1.1.33.10.exe" 1>"FileInstall01.ahk_1.1.33.10.exe.log" 2>&1 & echo {{{ & type "FileInstall01.ahk_1.1.33.10.exe.log" & echo }}} & echo [[[ & type "_ReadMe_01.txt" & echo ]]] )
{{{
vErrorLevel: 0 | vLastError: 0 | vLastException:
}}}
[[[
]]]
>
So, it appears that at least in specific circumstances (yet to clarify) the latest stable AutoHotkey version 1.1.33.10 erroneously generates zero-length files with its built-in command "FileInstall".
Just in case, we have also tried on Windows 7 (using different configuration, different anti-virus) but the problem still occurs, so it looks unlikely that this is related to a specific Windows set-up.
We would really need this functionality to work correctly for AHK scripts to run in our organisation, as it used to be with previous AHK stable versions.
Feel free to ask for any further explanations and/or details.
Many thanks again for the product and for its support!
