Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ANSI escape sequences to display colored output not handled correctly #1380

Open
samrat opened this issue Mar 22, 2020 · 4 comments
Open

ANSI escape sequences to display colored output not handled correctly #1380

samrat opened this issue Mar 22, 2020 · 4 comments
Labels
bug Incorrect behavior in the current implementation that needs fixing

Comments

@samrat
Copy link
Contributor

samrat commented Mar 22, 2020

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?

    1. Clone https://github.com/samrat/wasmtime-colored-output
    2. Build the wasm file: cargo build --target wasm32-wasi
    3. Run the file with wasmtime: 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...)

    rustc 1.43.0-nightly (564758c4c 2020-03-08)
    
    > uname -r                                                                                     
    5.5.9-arch1-2
    
@samrat samrat added the bug Incorrect behavior in the current implementation that needs fixing label Mar 22, 2020
@samrat
Copy link
Contributor Author

samrat commented Mar 22, 2020

Looks like this is a deliberate decision and there is a WASI issue discussing this: WebAssembly/WASI#162. I think this can be closed, given this is a known and deliberate limitation.

@rene-fonseca
Copy link

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.

@samrat
Copy link
Contributor Author

samrat commented Mar 23, 2020

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.

@sunfishcode
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect behavior in the current implementation that needs fixing
Projects
None yet
Development

No branches or pull requests

3 participants