Standalone executable

[misha-franz]

Do you think it would be nice to have an option to "compile" a script into a standalone executable (by adding it to the end of the expect.exe and reading on start)?

This way the resulting file can be shared with people who have little knowledge of Windows CLI. They will just need to run the app (via double click).

[hymkor]

@misha-franz Thank you for your suggestion.

Your idea is possible, but I am hesitant to implement it too casually because generating an executable file could be suspected as malware.

So if there are many requests, I will consider it.

[hymkor]

I tried implementing it experimentally.

• Release v0.12.0 · hymkor/expect

[misha-franz]

Thanks a lot!

I tested briefly and here are the observations.

When downloading, Chrome suggested to test for viruses and the app passed. Which is good, but no guarantee that eventually this will not change.

The app indeed creates an executable, which seems to work (though I only tested "hello").

I would allow executable name without .exe and would add .exe automatically since the app is for Windows only (unless you plan to port it).

Overall I think the usage message(s) require proof-reading and clean up:

• Maybe when the app started without argument it should start REPL. Otherwise it should show the same usage as with -h, but not usage: expect.exe xxxx.lua (some people may conclude the always expects xxxxx.lua.

• colorize the output; can be 'always' (default if omitted), 'auto', or 'never'. (default "always") <- it seems it repeats itself

• expect.exe -compile NEW-BINARY-FILENAME SCRIPT-FILENAM <- should not be on the same line with -compile, no need to use capitals.

• make all-in-one binary (expect.exe -compile NEW-BINARY-FILENAME SCRIPT-FILENAME) <- repeats info from previous line.

Sorry for too many comments. I understand this version is still experimental and you plan to work on clean up.

Again, many thanks for the useful feature!

[hymkor]

Thank you.

There was a specification in the Go language's option parsing library ("flag") that I didn't understand, which resulted in unnecessary duplication in the semi-automatically generated help.

(The help text was basically one line per option, and if any part of the content was enclosed in back-quotations, it would be replaced with the name of the option argument)

The new candidate of the usage :

$ ./expect.exe
Expect-lua v0.12.0-5-gc285fd7-windows-amd64 by go1.20.14
Usage of ./expect.exe:
  -color string
        colorize the output; 'always', 'auto', or 'never' (default "always")
  -compile new-executable
        make new-executable including a script. This does not execute the script immediately
  -e code
        execute code
  -nologo
        do not show logo
  -printembederror
        debug option. print errors of embed

Other changes to be implemented on the next version

1. When no arguments are given, show help
2. -compile new-executable : when new-executable does not end with .exe, append .exe

If there are any problems with the expression, please let me know your suggestions for correction.

[misha-franz]

Hi again,

Apology for the delay, was planning to reply yesterday.

• Usage line should probably look like"

Usage: expect.exe [options] [ Githubissues.

Githubissues is a development platform for aggregating issues.