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] [<script>.lua]
Options:
- ....

(./ does not make sense for Windows users)

• Maybe Expect-lua v0.12.0-5-gc285fd7-windows-amd64 by go1.20.14 should be only printed with usage, but not during normal operation. You can also add an option -v to print version info. I would probably add some info about the Lua interpreter in go you are using and a github link to your project.
• Not sure "by" can be used in this case (unless this is common practice in go projects). Maybe
  Expect-lua v0.12.0-5-gc285fd7-windows-amd64 using go1.20.14 (or in, with)
• color string
  colorize the output; 'always', 'auto', or 'never' (default "always")
  Maybe just
  -color always|auto|never
  colorize output; default always
  Likely need to explain the meaning of auto option
  -compile executable-name
  make executable with <script>.lua embedded; script is not executed
• -nologo
  do not show logo replace with
  -v
  print version info

-printembederror
debug option. print errors of embed looks confusing, maybe:

-verbose
     print debug info

Thanks again!

[misha-franz]

And apology for not providing a better organised feedback. Heavily multitasking but did not want to delay for long. Also one of my colleagues followed my recommendation and started using your excellent tool (he originally contacted me for help since I know Tcl/Tk and partially the original Expect, but I did not find a better solution for Windows). I can ask him to review the usage message since he is a native English speaker.

[misha-franz]

Forgot to mention. Is there a reason you are not using the latest version of go compiler?

[hymkor]

Is there a reason you are not using the latest version of go compiler?

Because Go1.20 supported Windows 7, 8.1, Server 2008, 2012.
I understand too old OS should not be used and I do not use, however I consider some people have to use them.

---

I would modify the usage-messages as possible , but due to the limitations of the Go language library, they are not very flexible. Therefore some of suggestions are difficult to implement.

-flagname XXXXX
    UUUUUUUUUUUU (default: DDDDD)

XXXXX must be contained in UUUUUUUUUUUU as `XXXXXX` if we change the value of XXXXX from default.

I will try to do what I can, so please wait a little while.

[hymkor]

Likely need to explain the meaning of auto option

auto is same as always. I do not know the reason auto exists, because the code for -color came from a pull request.
Therefore I add a new boolean option -nocolor instead of -color.
I keep the option -color, but hide from the usage.

A new usage will be displayed as below

Expect-lua v0.12.0-16-g560a13d-windows-amd64 with go1.20.14
Usage of .\expect.exe:
  -D    print debug information
  -compile executable-name
        compile executable with <script>.lua embedded; script is not executed
  -e code
        execute code
  -nocolor
        disable color

Though I mentioned the limitations of the option parsing library , I got around them with replacing the usage function from the standard library.
-nologo exists, but it is now hidden because logo is displayed only when no arguments or -h is specified.

[hymkor]

Release v0.12.1 · hymkor/expect