CLI --dir cannot represent directory paths containing literal `::`

[MacroModel]

The existing --dir=HOST::GUEST syntax is ambiguous when either path contains ::.

Consider supporting a two-argument form:

wasmtime --dir HOST GUEST program.wasm

The existing syntax could remain as a backward-compatible alias:

--dir=HOST::GUEST

This avoids introducing custom escaping rules and lets both paths represent valid filesystem names directly.

the ("--dir HOST GUEST" and "--dir=HOST::GUEST") two-argument behavior may be unclear.Consider:

wasmtime --map-dir A::B C::D program.wasm

The existing --dir syntax can remain supported for backward compatibility (only in the --dir=HOST::GUEST form). Meanwhile, --map-dir more clearly conveys that the first directory is mapped to the second, while avoiding the need for any custom escaping rules.

[tschneidereit]

Is this a problem you're hitting in practice and in ways you can't work around? I'm asking because introducing new CLI syntax isn't exactly cheap: it requires us to carefully reason through how existing uses might be broken by it or what side-effects otherwise might be, for example. And I'm pretty sure that your proposed syntax isn't something we'd want to do: it introduces ambiguity around whether something is a positional argument or an option, for example.

[MacroModel]

Is this a problem you're hitting in practice and in ways you can't work around? I'm asking because introducing new CLI syntax isn't exactly cheap: it requires us to carefully reason through how existing uses might be broken by it or what side-effects otherwise might be, for example. And I'm pretty sure that your proposed syntax isn't something we'd want to do: it introduces ambiguity around whether something is a positional argument or an option, for example.

Thanks for the clarification. I’m raising this primarily as a representational edge case, not suggesting that paths containing :: are common.

There is an important asymmetry between the host and guest sides.

On the host side, if the actual filesystem path contains :: and the user has permission to create a symlink or another alias, the issue can usually be worked around. For example, an alias without :: can point to the real system path containing ::, and that alias can then be passed to Wasmtime. The underlying host directory is still accessible; only the CLI-facing path needs to avoid the delimiter.

The guest-side preopen path does not have an equivalent workaround. The current parser splits on every occurrence of ::, takes only the first component as the host path and the second as the guest path, and silently discards the remaining components.

For example:

--dir=A::B::C

is parsed as host A and guest B; the trailing ::C is discarded. Therefore, the current CLI cannot assign a preopened directory the exact WASI guest path B::C.

Mapping a parent directory may allow a program to access a child whose name contains ::, but that only works when the program does not require the preopen itself to have that exact name. If a Wasm program specifically expects a preopened directory named B::C, there is currently no way to express that mapping through --dir.

I agree that --dir HOST GUEST may introduce ambiguity with positional arguments, so I’m not attached to that particular syntax. My main concern is that the current syntax cannot represent every otherwise-valid guest preopen path.

[tschneidereit]

I'm not sure about others, but I'm inclined to just leave this as-is. As you point out, there are host-side workarounds, and I think the scenario you describe where the guest absolutely must use :: is too far-fetched for us to spend time on. "the current syntax cannot represent every otherwise-valid guest preopen path" might be sufficient motivation with infinite amounts of time, but as-is, I doubt we'd ever run out of higher-priority work to take on first.