Does WebAssembly/WASI have access to /proc/PID/fd/0, /dev/stdin and equivalent on Apple devices?

[guest271314]

Does WebAssembly/WASI have access to /proc/PID/fd/0, /dev/stdin and equivalent on Apple devices?

WebAssembly/design#1521 (comment)

This would better be posted on https://github.com/WebAssembly/wasi-filesystem.

[pchickey]

WASI does not specify anything about what files are present in the filesystem, or if any files from the host OS are available. In some embeddings where the WASI program is considered fully trusted, the whole host filesystem may be available, but most implementations choose to limit the part of the filesystem available to WASI to a small subset of the host. For how each implementation makes that choice, you can consult their docs.

[guest271314]

For how each implementation makes that choice, you can consult their docs.

I wrote C and C++ versions of a Native Messaging host that reads standard input using wasmtime on the shebang line in a shell script https://github.com/guest271314/native-messaging-webassembly/blob/main/nm_c_wasm.sh, and using wasmtime through process substitution in a Bash script using embedded WAT https://github.com/guest271314/native-messaging-webassembly/blob/main/nm_c_wat.sh. So I know the capability exists.

I'm curious about two items within the same scope:

1. If WebAssembly/WASI specifies the capability to read standard input stream and write to standard output explicitly (as ECMA-262 does not spell out anything about standard input streams or standard output streams, though the vast majority of JavaScript engines and runtimes circa 2024, yet each implements I/O differently, perhaps precisely because there is no I/O standard for JavaScript). Your initial reply appears to indicate "No".

2. When using WebAssembly/WASI in a non-browser JavaScript environment such as V8's d8 shell or SpiderMonkery's js shell, if I use nm_c.wasm compiled from C https://github.com/guest271314/native-messaging-webassembly/blob/main/nm_c.c, say, for example with WebAssembly.compile(), can/should I expect that WebAssembly implementation to have access to /dev/stdin or /proc/PID/fd/0 out of the box, as we are not in a browser environment?

What I'm thinking about is using the base WebAssembly object and static methods to read standard input to V8's JavaScript/Webassembly engine d8 shell.

Right now I'm using bash -c and/or QuickJS to read stdin to d8 with os.system(), then sending d8's stdin to d8 https://github.com/guest271314/NativeMessagingHosts/tree/main?tab=readme-ov-file#native-messaging-documentation - because d8's readline() doesn't appear to be capable of processing a "32-bit message length in native byte order" (see https://github.com/guest271314/NativeMessagingHosts/tree/main?tab=readme-ov-file#native-messaging-documentation) from a non-TTY application, e.g., chrome or firefox-bin. d8 wants to execute the input, expecting input from a TTY (commandline repl).

It sure would be useful if WebAssembly/WASI explicitly spelled out: "Step 1. Read stardard input into WebAssembly.Memory, or resizable ArrayBuffer, or WHATWH ReadableStream, et al. Step 2. If no more data in stream ...", explicitly, without ambiguity, so that Apple, Linux, Windows, SerenityOS, et al. users could point to and use that clear language. Instead of there being the capability to do so, whether in JavaScript alone, or WebAssembly/WASI, yet a complete omission of formal standardization of streams https://cseweb.ucsd.edu/classes/fa01/cse221/papers/ritchie-stream-io-belllabs84.pdf.

Just a thought. Thanks for your consideration.

[pchickey]

The stdin and stdout streams use these interfaces in the wasi-cli package, which are distinct from the filesystem: https://github.com/WebAssembly/wasi-cli/blob/main/wit/stdio.wit . Rather than exposing those streams as files, they are exposed just as the more primitive input-stream and output-stream types from wasi-io. Additional information for implementing isatty is provided in these interfaces https://github.com/WebAssembly/wasi-cli/blob/main/wit/terminal.wit . One of the design principles in WASI is to use more specific types and interfaces, where possible, than the poxix principle of everything is a file.

WASI is specified using the Component Model wit language to define types and function signatures, and the wasi-io docs are intended to be the layer on top of that which describes how input-stream and output-stream work: https://github.com/WebAssembly/wasi-io/blob/main/wit/streams.wit . If you find that specification isn't clear enough to write an implementation or client of that code, please open an issue on the wasi-io repo and we can improve it.

[guest271314]

I've got some reading and testing to do. Thanks.