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.wasm
And it can be run in this way:
$ wasmtime run echo.wasm
The program will start and I'll be able to enter my text. The program will keep reading from STDIN until I send the
EOF
symbol (I'm on Linux ->CTRL-D
).Unfortunately the
input
variable 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
input
object 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-wasi
handles STDIN/STDOUT/STDERR by using instances of the Descriptor class. The library simply opens the file descriptor0
for STDIN,1
for STDOUT and2
for STDERR. In my tests it looks like opening the file descriptor0
always returns anull
instance 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 anull
object 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.wasm
And it can be run in this way:
$ wasmtime run echo.wasm
The program will start and I'll be able to enter my text. The program will keep reading from STDIN until I send the
EOF
symbol (I'm on Linux ->CTRL-D
).Unfortunately the
input
variable 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
input
object 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-wasi
handles STDIN/STDOUT/STDERR by using instances of the Descriptor class. The library simply opens the file descriptor0
for STDIN,1
for STDOUT and2
for STDERR. In my tests it looks like opening the file descriptor0
always returns anull
instance 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 anull
object 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 23 2024 at 13:07 UTC