How to intercept command inputs and command outputs

[loveencounterflow]

I have an idea for a web app I want to build. It should basically be an xterm terminal acting as input (in my case backed by ZSH in node-pty) and a display area as output above that. I want to intercept what commands the user is issuing and what the return values for that are and, depending on the data, display it in the output. I know I can use events on the websocket, on the PTY instance, and on term.onData(), however, none of these seem to give me what I'd need, namely, a clean separation of what commands the user executes and whatever data that results in; I'd basically have to look at all cursor movements and re-implement ZSH's behavior in order to know what commands got actually executed. Can anyone give me some pointers how to cleanly separate in- and output?

[jerch]

however, none of these seem to give me what I'd need, namely, a clean separation of what commands the user executes and whatever data that results in ...

Correct, that is inherently not possible with what OSes have with PTY and command shells these days, at least not in a reliable fashion.

What would get you close is writing your own command shell, where you control every aspect of the involved file descriptors and limit the commands down to non-interactive commands only, e.g. no interactive python call either. As soon as you allow ppl to run their own interactive programs like the python interpreter, that has its own sub commands and can spawn own DSL-based shells you lose the control again. There are some tricks possible with interactive programs (like putting them into their own PTY enclave) - but with those tricks you again would only know, that a certain output came from those, but still not know semantically, what to make of the outputs.

So yeah, with a custom shell some control is possible but it is still very error-prone and only possible with a heuristic approach. In every case the terminal is the wrong point to put those logic, as it is just an IO device not aware of the program on the "other side". (In other words - you also would not ask the graphics card, which program rendered pixel xy, but try to get that info from the "desktop shell", which is typically baked into your window manager...)

[loveencounterflow]

I was afraid I'd get that answer :-(

For future reference, I'll post part of the answer I got from ChatGPT:

[...] you can’t get a clean command/response split at the xterm.js or PTY level without extra help, because terminals were never designed to give you that.

[...]

• The terminal is just a byte stream. ZSH writes prompts and command echoes, then executes external programs which also write arbitrary bytes (including cursor moves, overwrites, color codes). The PTY and xterm.js just pass those along.

[...]

The key is: don’t try to parse at the terminal level. Instead, get ZSH (or whatever shell) to explicitly tell you what’s going on.

[...]

ZSH has powerful hooks that run before and after each command:

preexec() { print -n "\033]133;C;$1\007" }
precmd() { print -n "\033]133;D\007" }

Here we’re printing OSC escape sequences (which you can detect out-of-band in your PTY).
This way, your Node.js side can watch for ]133;C; (command start) and ]133;D (command done) and use that as markers.

👉 This is how VS Code’s “integrated terminal” detects executed commands.

[...]

I think insofar the hint about VS Code's implementation is correct, it's a strong indicator that that's the way to go.

[jerch]

Lol, well the AI answer is not quite correct - the OSC sequences do not come out-of-band, they are strictly in-band messages on the PTY file descriptors.

You should not rely on modern command shells for command serialization without heavy customization, as modern shells like bash zsh etc. allow concurrent command execution from scripts etc, which makes identifying the origin of a certain output even worse.

[loveencounterflow]

Yeah, AI at this point is more like a suggestion when you go into the details...

I think we can close this thread, but before I go: do you know of any more modern takes how to organize a command-line-like workflow that provides proper identification of inputs and outputs, maybe something that can actually render all kinds of media?

Somehow we've painted ourselves into a corner here. I mean developers are typically enthusiastic about how powerful the command line is but OTOH the single most powerful piece of the puzzle of how to adapt software to new needs—extensibility—is severely lacking.

[davidfiala]

(not trying to solicit, just provide an FYI)

Commercially, I have this implemented. I'm not aware of any open source options that do it cleanly, correctly.

One must separate the PTY of every command. Doing that while maintaining perfect shell state and continuity without resorting to cheats like serialization and rehydrating state... That's the part that's hard and requires creativity.

As a potential pointer, Warp had done something like this (maybe OSS?), but last I checked their specific impl was not something I could trust from a security perspective.

[jerch]

I had several discussions about that in the past. From a kernel perspective the TTY layer lacks message boundaries (could be achieved with message queues) and the process notion. Both would be doable (as the primitives are all there already) and I think the systemd folks also once tried to get the TTY layer more open to custom setups. But here comes the POSIX restriction - it is a mammoth with lots of ancient heritage to maintain, so it is very unlikely to see any shift into that direction on system level.

So until then you can get somewhere with isolated PTYs for subcommands and some clever heuristics and OSC annotations. But reliable solvable is it only when done on system level.