Open samrat opened 4 years ago
Looks like this is a deliberate decision and there is a WASI issue discussing this: https://github.com/WebAssembly/WASI/issues/162. I think this can be closed, given this is a known and deliberate limitation.
The common color codes should be supported for stdout. But you can try to use stderr instead of stdout to see if it works and isn't due to some other problem. stderr should not be filtering the codes at the moment.
Thanks @rene-fonseca.
This could be due to some other problem as this behaviour seems to be happening when I change to output to stderr as well.
Allowing untrusted portable code write directly to a user's terminal is not something any serious system I'm aware of has ever knowingly done before, so we're researching how we can enable this functionality in a way that protects users and provides portability. As a temporary measure, streams which are attatched to ttys, which includes both stdout and stderr, are filtered to neutralize escape sequences and problematic control characters.
I experienced this bug when trying to run the [QuickJS wasm] file. I have created a repo to reproduce the issue.
What are the steps to reproduce the issue?
cargo build --target wasm32-wasi
wasmtime target/wasm32-wasi/debug/wasmtime-colored-output.wasm
What do you expect to happen? What does actually happen? Does it panic, and if so, with which assertion? I expected to see colored output, the ASCII escape codes are displayed instead.
Which Wasmtime version / commit hash / branch are you using?
c202a8eea
If relevant, can you include some extra information about your environment? (Rust version, operating system, architecture...)