Does the current spec allow for things like ioctl and termios?

[torch2424]

Hello,

Context

Been working on a fun little CLI project, to do matrix rain effect using the Wasi bindings, and using wasa.

I'm using Wapm / Wasmer to run my Wasm module.

What I think is the problem

I opened this issue on my project: torch2424/wasm-matrix#1 . Which Essentially comes down to, I can't figure out how to get the terminal size using the current available Wasi bindings.

I think what I would need from Wasi is someway to use a the underlying effect of C's ioctl or termios. Is this something you can do with the current WASI bindings? If so, how? If not, is this planned to be done at some point? I understand that Wasm / Wasi are super young, so no worries if it is planned, not looking for an ETA or anything.

cc @dcode , as I originally opened this at: AssemblyScript/assemblyscript#587 . And cc @binji because we chatted about it earlier today 😂

And thanks for all the hard work! Wasi is super cool / exciting. 😄 Thanks!

[sunfishcode]

The short answer is no, this isn't possible within the current WASI API.

Beyond that, there are several things which are unportable about the code, for example:

export const GREEN: string = ESC + "32m";
export const WHITE: string = ESC + "37m";
export const RED: string = ESC + "31m";
export const CYAN: string = ESC + "36m";
export const RESET: string = ESC + "0m";

These assume your program's stdout is connected to an ANSI-style terminal. However, the kind of portability we're aiming for with WASI extends beyond platforms like Unix which tend to have ANSI-style terminal emulation. So while this is a neat program with a unique visual effect, enabling programs that only work on one kind of platform isn't the goal we're really aiming for here.

With WASI, we're really looking at the long term. Enthusiasm and cool demos in the short term are fun, but to make progress towards our ultimate goals we must also distinguish between things which show off what WASI can actually do, and things which reach outside of what WASI can do and give false impressions, and potentially distract from the work needed to reach our goals.

It is likely that in the future WASI will add ways to do color output, cursor positioning, and then also terminal size detection, and so on, and it could conceivably do so in a way that's compatible with ANSI escape codes. If someone is interested in starting a proposal to spell out what functionality would be required, and what the interfaces should be, that'd be a great place to start!

[KronicDeth]

I’d have to look at their code to be sure, but looking at how JetBrains IDEs or Atom or VSCode handle terminals could show us how to make OS neutral terminal APIs since they all have MacOS, Linux, and Windows support.

[dumblob]

@leonerd could you maybe sketch your view on this? Especially in accordance to the last paragraph in the comment of @sunfishcode above.

[PoignardAzur]

I’d have to look at their code to be sure, but looking at how JetBrains IDEs or Atom or VSCode handle terminals could show us how to make OS neutral terminal APIs since they all have MacOS, Linux, and Windows support.

I've worked on an IDE plugin for Atom as an end-of-study project.

To spawn an integrated terminal, we used nuclide-prebuilt-libs/pty, which is a precompiled binary of node-pty, which is also what VS-code uses.

As far a compatibility goes, it looks like node-pty is based on the POSIX function forkpty, with bindings to ConPTY for Windows compatibility. I have no idea whether any of this is relevant to WASI.

[sunfishcode]

The original question has been answered here. If anyone has any further questions, feel free to file new issues!