flavio opened Issue #2373:
I hope I'm opening this bug on the right GitHub repo, if not please forgive me :sweat_smile:
I've written a simple "echo" program using AssemblyScript and as-wasi. The program reads the user input from STDIN and writes it back to STDOUT.
Unfortunately it looks like I can never get back the input I enter.
- What are the steps to reproduce the issue?
This the source code of the AssemblyScript program I'm running:
import "wasi" import {Console} from "as-wasi" Console.log("type something"); let input: string | null; let msg : string = "nothing"; input = Console.readAll(); if (input != null) { msg = input! } Console.log('I got: ' + msg);The program can be compiled to a WASM binary by doing:
$ asc echo.ts -b echo.wasmAnd it can be run in this way:
$ wasmtime run echo.wasmThe program will start and I'll be able to enter my text. The program will keep reading from STDIN until I send the
EOFsymbol (I'm on Linux ->CTRL-D).Unfortunately the
inputvariable is alwaysnull.
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?I would expect the WASM program to be able to read data from stdin. The
inputobject should hold the text I entered on my terminal.
- Which Wasmtime version / commit hash / branch are you using?
This is my stack:
* wasmtime: 0.21.0
* AssemblyScript: 0.17.1
*as-wasi: 0.4.0
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)I'm running on a x86_64 Linux box that has openSUSE Tumbleweed
More information...
The
as-wasihandles STDIN/STDOUT/STDERR by using instances of the Descriptor class. The library simply opens the file descriptor0for STDIN,1for STDOUT and2for STDERR. In my tests it looks like opening the file descriptor0always returns anullinstance ofDescriptor; this doesn't happen with STDOUT and STDERR.The same issue happens also when running the program through a custom made Go program I wrote leveraging
wasmtime-go.
In that case I even tried to start the WASM binary not by inheriting the parent STDIN, but instead by using a text file I previously created. Also in this case the WASM binary got anullobject when reading from the STDIN.Relevant: a similar WASM binary, generated by translating Rust -> WASM, just works as expected.
Thanks for any kind of help you can give me. I gotta say, WebAssembly and wasmtime are really cool :)
flavio labeled Issue #2373:
I hope I'm opening this bug on the right GitHub repo, if not please forgive me :sweat_smile:
I've written a simple "echo" program using AssemblyScript and as-wasi. The program reads the user input from STDIN and writes it back to STDOUT.
Unfortunately it looks like I can never get back the input I enter.
- What are the steps to reproduce the issue?
This the source code of the AssemblyScript program I'm running:
import "wasi" import {Console} from "as-wasi" Console.log("type something"); let input: string | null; let msg : string = "nothing"; input = Console.readAll(); if (input != null) { msg = input! } Console.log('I got: ' + msg);The program can be compiled to a WASM binary by doing:
$ asc echo.ts -b echo.wasmAnd it can be run in this way:
$ wasmtime run echo.wasmThe program will start and I'll be able to enter my text. The program will keep reading from STDIN until I send the
EOFsymbol (I'm on Linux ->CTRL-D).Unfortunately the
inputvariable is alwaysnull.
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?I would expect the WASM program to be able to read data from stdin. The
inputobject should hold the text I entered on my terminal.
- Which Wasmtime version / commit hash / branch are you using?
This is my stack:
* wasmtime: 0.21.0
* AssemblyScript: 0.17.1
*as-wasi: 0.4.0
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)I'm running on a x86_64 Linux box that has openSUSE Tumbleweed
More information...
The
as-wasihandles STDIN/STDOUT/STDERR by using instances of the Descriptor class. The library simply opens the file descriptor0for STDIN,1for STDOUT and2for STDERR. In my tests it looks like opening the file descriptor0always returns anullinstance ofDescriptor; this doesn't happen with STDOUT and STDERR.The same issue happens also when running the program through a custom made Go program I wrote leveraging
wasmtime-go.
In that case I even tried to start the WASM binary not by inheriting the parent STDIN, but instead by using a text file I previously created. Also in this case the WASM binary got anullobject when reading from the STDIN.Relevant: a similar WASM binary, generated by translating Rust -> WASM, just works as expected.
Thanks for any kind of help you can give me. I gotta say, WebAssembly and wasmtime are really cool :)
Last updated: Dec 13 2025 at 19:03 UTC