Stand-alone syntax validator?

[alexdresko]

Hello!

Is there a way to verify that the syntax in my .AHK file is correct without actually executing it? I tried the compiler and it just seems to spit out an .exe even if it's not a valid .AHK file.

Thanks in advance for your time!

[lifeweaver]

Hi alexdresko,

You might merely add #Persistent and a return at the top so it gets interpreted but doesn't actually do anything, or perhaps try out #warn.

[lexikos]

If you use /ErrorStdOut, any load-time error that occurs will be written to StdErr. If you use /iLib, the script won't be executed even if there are no errors.

Code: Select all

FileAppend MsgBx`n, ~badscript.ahk

MsgBox % ScriptErrors("~badscript.ahk")

FileDelete ~badscript.ahk

ScriptErrors(Script)
{
    return ComObjCreate("WScript.Shell")
        .Exec("AutoHotkey.exe /iLib nul /ErrorStdOut """ Script """")
        .StdErr.ReadAll()
}

/iLib normally creates a file listing any stdlib auto-includes that your script uses. Using nul prevents this. (nul is a feature of the file system, and can be used with many other programs.)

If there are no load-time errors, the output is empty.

[Cerberus]

If you use /ErrorStdOut, any load-time error that occurs will be written to StdErr. If you use /iLib, the script won't be executed even if there are no errors.
...
/iLib normally creates a file listing any stdlib auto-includes that your script uses. Using nul prevents this. (nul is a feature of the file system, and can be used with many other programs.)

If there are no load-time errors, the output is empty.

This is a very nice minimal example, thanks. I have noticed that it somehow won't work with Unicode. Is that a limitation of Windows exec, or am I doing something wrong? I'm trying to find a work-around, but I have so far failed:

Code: Select all

FileAppend ¾ ž é ō Û`n, ~badscript.ahk, UTF-8      		; Result: ¾ ? é ? Û
; FileAppend ¾ ž é ō Û`n, ~badscript.ahk, UTF-16   		; Result: ¾ ? é ? Û
; FileAppend € é Û`n, ~badscript.ahk, UTF-8    		; Result: � é �
FileRead, FileContent, ~badscript.ahk
Msgbox % "This is the correct content: " FileContent	; Result: ¾ ž é ō Û (correct)
ErrorString := ScriptErrors("~badscript.ahk")
ErrorString := RegExReplace(ErrorString, "si)^.*Specifically:(.*)$", "$1")
MsgBox % "This is the output from the ScriptErrors functions: " ErrorString    ; Result: ¾ ? é ? Û
FileDelete ~badscript.ahk

; The below is a file specifically saved as UTF-8 with BOM, containing ¾ ž é ō Û
; MsgBox % ScriptErrors("D:\Dropbox\Autohotkey\unicode_test_script.ahk")    ; Result: ¾ ? é ? Û

ScriptErrors(Script){
    return ComObjCreate("WScript.Shell")
        .Exec("AutoHotkey.exe /iLib nul /ErrorStdOut """ Script """")
        ; .Exec("AutoHotkey.exe /iLib nul /ErrorStdOut /CP65001 """ Script """")    ; Makes no difference
        .StdErr.ReadAll()
}

Fiddling with file encoding doesn't same to change anything. Since the file can be read correctly (FileRead, FileContent, ~badscript.ahk), the problem seems to lie somewhere inside the ScriptErrors function.

The saved file (see commented-out code above) I used was this:

Code: Select all

¾ ž é ō Û

[iPhilip]

Hi Cerberus,

I ran your code and got the following output:

Code: Select all

C:\~badscript.ahk (1) : ==> This line does not contain a recognized action.

     Specifically: ¾ ž é ō �

I am running AHK v1.1.30.01 U32.

I hope this helps.

- iPhilip

[Cerberus]

I am running AHK v1.1.30.01 U32.

Hey, thanks for testing! So you got yet another error! Now we have two completely different outputs, yours and mine, but both incorrect. Did the first message box display the correct symbols for you?

You're running 32-bit Autohotkey; I'm running 64-bit. We're running the same version v1.1.30.01. I'm on Windows 10 Pro.

This is far beyond my skill, alas. Perhaps someone will be able to make something of this in the future...

[iPhilip]

FYI. I ran it with U64 and got the same result.

[FanaticGuru]

I am running AHK v1.1.30.01 U32.

Hey, thanks for testing! So you got yet another error! Now we have two completely different outputs, yours and mine, but both incorrect. Did the first message box display the correct symbols for you?

You're running 32-bit Autohotkey; I'm running 64-bit. We're running the same version v1.1.30.01. I'm on Windows 10 Pro.

This is far beyond my skill, alas. Perhaps someone will be able to make something of this in the future...

I ran on AHK v1.1.30.01 U64 with Windows 10 Home. USA system with no international stuff going on.

It ran fine with the expected error identificaion.

FG

[Cerberus]

I ran on AHK v1.1.30.01 U64 with Windows 10 Home. USA system with no international stuff going on.
It ran fine with the expected error identificaion.
FG

Thanks for testing! Gosh, how odd. The second message box gives ¾ ? é ? Û for me. My system is set to American English, using the American standard keyboard as well. I use Dutch regional settings, but changing those to American didn't make any difference. My Windows is a fairly recent install, Windows 10 Pro. Everything else works perfectly as well, and I have never come across any Unicode issues outside Autohotkey. I have no idea what else to look for. Might it have something to do with unusual file locations, or something? Or some setting in Windows that I don't remember changing? Or could it be because I'm a few Windows updates behind?

P.S. When I compile the script, I get an error when I run it, telling me Exec cannot be found or something. Is that normal?

[hd0202]

may I ask what this means in ahk (in your opinion) :
¾ ž é ō Û

Hubert

[Cerberus]

may I ask what this means in ahk (in your opinion) :
¾ ž é ō Û

Hubert

It means nothing; it's just a test for Unicode characters. I am using this in a linter: when you type text in an editor, it automatically shows you errors. The problem is that it won't show the error correctly if there are certain Unicode characters in the error message. The above is the shortest way to cause such an error message to be generated. A realistic example would be Amount := "€ 100. This gives an error message, as the closing quotation marks have been omitted. But the error message is not displayed correctly (will show Amount := "? 100).

[FanaticGuru]

I ran on AHK v1.1.30.01 U64 with Windows 10 Home. USA system with no international stuff going on.
It ran fine with the expected error identificaion.
FG

Thanks for testing! Gosh, how odd. The second message box gives ¾ ? é ? Û for me. My system is set to American English, using the American standard keyboard as well. I use Dutch regional settings, but changing those to American didn't make any difference. My Windows is a fairly recent install, Windows 10 Pro. Everything else works perfectly as well, and I have never come across any Unicode issues outside Autohotkey. I have no idea what else to look for. Might it have something to do with unusual file locations, or something? Or some setting in Windows that I don't remember changing? Or could it be because I'm a few Windows updates behind?

P.S. When I compile the script, I get an error when I run it, telling me Exec cannot be found or something. Is that normal?

I did not read the thread correctly. I was running the OP without problem.

When I run your code, I get the same unexpected result of ¾ ? é ? Û.

I have no idea what is causing this problem. I tried encoding with: UTF-16 Big Endian, UTF-16 Little Endian, UTF-8 with BOM, and UTF-8. All the encoding options my editor had and none gave the correct result.

FG

[Cerberus]

I did not read the thread correctly. I was running the OP without problem.

When I run your code, I get the same unexpected result of ¾ ? é ? Û.

I have no idea what is causing this problem. I tried encoding with: UTF-16 Big Endian, UTF-16 Little Endian, UTF-8 with BOM, and UTF-8. All the encoding options my editor had and none gave the correct result.

FG

Thank you very much for retesting! So it's not my system, after all. I tried the same things you did. I suspect it might be a Windows issue, but I don't know who might be able to tell us more.

[lexikos]

Is that a limitation of Windows exec [...]?

Yes. The workaround is to use CreateProcess directly. Search "StdoutToVar" for examples.

[Cerberus]

Is that a limitation of Windows exec [...]?

Yes. The workaround is to use CreateProcess directly. Search "StdoutToVar" for examples.

Oh, it seems I never replied to you. Thank you for clearing this up! At least I know I'm not crazy now. Meanwhile, SKAN has posted a new version of 'StdoutToVar':
https://www.autohotkey.com/boards/viewtopic.php?f=6&t=74647
I noticed DllCall("CreateProcess", ... ) in the code. But it has the same problem as the method using Exec above: it produces garbled Unicode characters. Is this whole thing perhaps entirely impossible after all?

[lexikos]

WSH Exec is limited to ANSI, but so is ErrorStdOut. Even if you replace WSH Exec with something that expects UTF-8, ErrorStdOut will still give it ANSI. It is not possible to change this without modification at the source. I think calling _setmode(_fileno(stderr), _O_U8TEXT); at startup (_tWinMain) is sufficient if you'll only ever output to something that expects UTF-8.

[Cerberus]

@Lexicos Thank you for your reply! It seems HotkeyIt has found a way to make it work, by adding a locale option to ERR_PRINT in the source code:

AFAIK, in ahk source code for unicode build setlocale() needs to be added to ERR_PRINT -> #define ERR_PRINT(fmt, ...) _ftprintf(stderr, fmt, __VA_ARGS__, setlocale(LC_ALL, ".65001")).
Just tested the fix and seems to work fine.

He has also proposed the change on Github:
https://github.com/Lexikos/AutoHotkey_L/pull/173

[lexikos]

if you'll only ever output to something that expects UTF-8.

To be receiving correct non-ASCII output (if limited in the range of characters), tools currently must decode AutoHotkey's stderr by using the system default ANSI codepage. If the codepage of the output is changed, any such tool would cease to work with even the limited subset of non-ASCII characters until it is reconfigured to expect UTF-8, if even possible for that tool. This is effectively a compatibility-breaking change, unless it is optional and disabled by default.