Why is there an extra -1 attached to the end of input?

[xxuejie]

I was toying around with this project, and I noticed that sometimes, the input data gathered from xterm/pty side, seems to contain an extra -1.

Upon some investigation I managed to narrow down to this line, so the question is: why appending an extra -1 here? Is this due to some historic conventions?

Many thanks!

[mame]

Thank you for playing with xterm-pty!

TBH I don't remember my intention precisely, so I could be wrong, but I think it represents "IO flush". The Emscripten runtime reads from stdin by calling tty_ops.getchar, but it appeared not to process the read characters immediately, but to do so after tty_ops.getchar returns null. The following condition converts the -1 in question to null.

xterm-pty/src/emscriptenHack.ts

Line 37 in 06e1c8f

return c >= 0 ? (c < 128 ? c : c - 256) : null;

However, we may add -1 on the myGetchar side instead of ttyServer for the purpose. I might try it later.

[xxuejie]

Thanks for the reply!

I couldn't find any reference regarding "IO flush", however it could be due to an emscripten quirk.

On a slightly different topic: I've been recently building a WASM-powered PTY app, and I run into xterm-pty. While currently xterm-pty works with emscripten based apps, there's nothing really stopping us using it to run a WASM app. In the WASM world, there's a de-facto standard named WASI, which defines a set of ABIs for WASM apps, including IO operations and so on. So I started playing out an idea: what if I build a WASI polyfill connecting a WASM PTY app to xterm-pty?

After a few days' hacking, I do have some initial code in this repository. I also have a demo at here, it basically compiles linenoise using wasi-sdk, and run it in the browser. For more technical details into the demo, you can check out the source code at here.

Note apart from this C demo, I do have a relatively larger demo, where I compile ckb-vm, a full RISC-V interpreter (written in Rust) to WASM and run it via xterm-pty in the browser. I'm still cleaning up the code for this, hopefully I can release it in a couple of days.

However, it does require some changes to xterm-pty to support this new WASI use case, I have the changes put together in this commit. Specifically, the changes include:

• A new entrypoint exporting TtyClient as well as Termios
• The above discussed part, where -1 is removed. I added this change as an option so the new code can in fact be compatible to both WASI and emscripten world

With the background explained above, I do have some questions for you:

• Are you interested in a new WASI backend for xterm-pty? Right now I only have just enough code in xterm-pty-wasi-polyfill, but I am interested in growing it into a more feature complete project to support PTY apps in the browser. If you also like this path, we can discuss how we can collaborate
• Regarding the changes on xterm-pty, are you interested in merging them to upstream? I can send a pull request if you feel like it.

Again, thanks for such an interesting project! Look forward to seeing it continues to grow.

[xxuejie]

And here's the Rust based RISC-V interpreter I'm talking about: https://github.com/xxuejie/instant-riscv

[mame]

@xxuejie Sorry for the late reply!

I couldn't find any reference regarding "IO flush", however it could be due to an emscripten quirk.

Yes, it is very Emscripten-specific. You can see the comment "get_char has 3 particular return values: ... c.) null to signal an EOF" in get_char of Emscripten.

However, I'd like to handle the hack in emscriptenHack, and keep ttyServer plain. I merged #2 so now the hack was removed from ttyServer.

However, it does require some changes to xterm-pty to support this new WASI use case ... A new entrypoint exporting TtyClient as well as Termios

I am okay for the existing workerTool to export Termios, but do you want to have a separate entrypoint? That will be fine if the new entrypoint includes a lot of polyfills for WASI.

The above discussed part, where -1 is removed.

I think this will be fixed by #2.

Are you interested in a new WASI backend for xterm-pty?

I like the idea, and I actually want to run a Ruby interpreter built with WASI with xterm-pty. It would be nice if it could be integrated with the existing wasi runtime like Wasmer JS.
However, we have to provide tcgetattr/tcsetattr independently from WASI, don't we? I'm a little concerned that it's not pure WASI.

Regarding the changes on xterm-pty, are you interested in merging them to upstream?

Welcome, of course!