wasi-cli icon indicating copy to clipboard operation
wasi-cli copied to clipboard

clarify expectations around the workdir concept

Open codefromthecrypt opened this issue 2 years ago • 2 comments

It is increasingly the case that people are conflating WASI with docker, likely due to the increase of tool integrations lately. Folks using docker are used to WORKDIR instructions and CLI overrides such as -workdir.

It isn't clear (to me) why the initial directory cannot be passed to a WASI command, similar to how we are able to pass ENV variables. We should at least document if the next WASI will continue to defer this to wasi-libc with an initial workdir (CWD) of "/", or understand what if any change is likely to occur.

codefromthecrypt avatar Mar 13 '23 05:03 codefromthecrypt

To add some color, this is how we have currently handled setting up the working directory in the Go WASI implementation https://github.com/Pryz/go/blob/dev-wasi-snapshot-preview1/src/syscall/fs_wasip1.go#L401-L405

	if cwd, _ = Getenv("PWD"); cwd != "" {
		cwd = joinPath("/", cwd)
	} else if len(preopens) > 0 {
		cwd = preopens[0].name
	}

Then we expect the caller of the runtime to set the PWD environment variable, defaulting to the first preopen if it is not set.

achille-roussel avatar Mar 24 '23 15:03 achille-roussel

also lacking this, tinygo hack wasmtime to mount pre-opens named ".." "../.." etc to let paths resolve relative the working directory https://github.com/tinygo-org/tinygo/blob/9027c50405b13ca48859bc82c660840140621ed5/main.go#L289

codefromthecrypt avatar Mar 24 '23 15:03 codefromthecrypt