Stream: git-wasmtime

Topic: wasmtime / issue #7695 --dir behavior appears to change w...

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 17:44):

brendandburns edited issue #7695:

@brendandburns ➜ /workspaces/dev-wasm-go (main) $ WASMTIME_NEW_CLI=1 wasmtime main.wasm --dir=.::.
Hello Go World!
Error writing open test.txt: errno 76
@brendandburns ➜ /workspaces/dev-wasm-go (main) $ WASMTIME_NEW_CLI=0 wasmtime main.wasm --dir=.
Hello Go World!
Wrote file
Copied file

Note that with the old CLI the wasm program works, with the new CLI it doesn't. I'm not sure if this is on purpose, but if it is what is the correct new syntax?

Test Case

WASM file uploaded. If you want to rebuild see:
https://github.com/dev-wasm/dev-wasm-go?tab=readme-ov-file#simple-example

Versions and Environment

Wasmtime version or commit: 15.0.1

Operating system: Linux

Architecture: amd64

main.zip

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 18:31):

alexcrichton commented on issue #7695:

Without the env var the original invocation prints:

$ wasmtime main.wasm --dir=.::.
warning: this CLI invocation of Wasmtime will be parsed differently in future
         Wasmtime versions -- see this online issue for more information:
         https://github.com/bytecodealliance/wasmtime/issues/7384

         Wasmtime will now execute with the old (<= Wasmtime 13) CLI parsing,
         however this behavior can also be temporarily configured with an
         environment variable:


         - WASMTIME_NEW_CLI=0 to indicate old semantics are desired and silence this warning, or
         - WASMTIME_NEW_CLI=1 to indicate new semantics are desired and use the latest behavior
Hello Go World!
Wrote file
Copied file

which indicates that this is being parsed differently with/without the new CLI. There's a more extensive writeup in the release notes but the short version is that this is behaving as expected.

The first invocation from above, WASMTIME_NEW_CLI=1 wasmtime main.wasm --dir=.::., is parsed as passing --dir=.::. to the main.wasm program itself, not Wasmtime. This behavior is explicitly opted-in to with the env var. The second invocation WASMTIME_NEW_CLI=0 wasmtime main.wasm --dir=. is forcing the usage of the old CLI (also the current default behavior) which parses --dir=. as an argument to Wasmtime itself.

I'll also note that switching the order of the arguments, wasmtime --dir=.::. main.wasm, gets this program working with/without the env var.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 18:47):

brendandburns commented on issue #7695:

Ah, so if I'm reading this correctly the ordering matters in the new CLI and not in the old CLI.

fwiw, having flag ordering matter without the explicit -- violates the posix file spec, specifically:

Guideline 11:
The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. If an option that has option-arguments is repeated, the option and option-argument combinations should be interpreted in the order specified on the command line.

from https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 18:55):

brendandburns edited a comment on issue #7695:

Ah, so if I'm reading this correctly the ordering matters in the new CLI and not in the old CLI.

fwiw, having flag ordering matter without the explicit -- violates the posix file spec, specifically:

Guideline 11:
The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. If an option that has option-arguments is repeated, the option and option-argument combinations should be interpreted in the order specified on the command line.

And the definition of the -- from:

Guideline 10:
The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

from https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 18:56):

brendandburns edited a comment on issue #7695:

Ah, so if I'm reading this correctly the ordering matters in the new CLI and not in the old CLI.

fwiw, having flag ordering matter without the explicit -- violates the posix flag/optarg spec, specifically:

Guideline 11:
The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. If an option that has option-arguments is repeated, the option and option-argument combinations should be interpreted in the order specified on the command line.

And the definition of the -- from:

Guideline 10:
The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

from https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

Last updated: Nov 22 2024 at 17:03 UTC