Preparsing onData Events

[SterlingButters]

This issue will kind of touch the following:
#56
#384

So I noticed that running certain commands will result in an inconsistent number of onData event fires. Prior to this realization, my thought was to use each event fire to sort the data output from the pty. For example, running ls would output 1) the command executed (and tbh idr if that included the cwd prompt) 2) the results of the command and 3) the cwd prompt. Perfect! If this was the case for all command executions then it would be much easier to handle those events in xterm.js.

Thus, the idea is for onData events to be partitioned into onExecCommand, onOutput and onCwdPrompt listeners. As stated previously, sometimes the number of onData event fires is inconsistent (using cat for instance does not fire the cwd prompt in a separate onData event). I had planned to attempt this with string matching however my ignorance of node-pty source has me hoping for a more elegant solution which may or may not be incredibly difficult.

Note that this suggestion does not utilize extraction of the error code (as for my use it doesn't seem needed if you are displaying everything in xterm). However, I do have an idea for this as well. The problem I am having is that the onData events capture EVERYTHING. My idea (however feasible) would be to implement what I will coin pty.stealthWrite(<data>) which writes to the pty in way that that the user can grab onStealthData events. The purpose of this would be to send onStealthData events through a separate socket channel to xterm.js where printing to the terminal could be handled differently than normal data events in the pty. For most cases I don't see this being particularly difficult in the following pseudo-logic:

if last ptyWrite == stealth
    ptyOnData == stealth

This would allow the user to grab data from the pty that you can choose not to display in xterm.js! More specifically, users can send standard bash commands to extract information from the pty which can be arbitrarily displayed in xterm.js (like $? to get the error code of the last command).

Eager to hear thoughts on this @jerch @Tyriar

[mofux]

The onData event can fire with just a single character, or with multiple lines of characters. This heavily depends on the OS and the program producing the output. From my experience there is no reliable way to capture the start or end of a command.

node-pty has absolutely no semantic knowledge of the data that is sent to or received from the pty.

You could however hook into xterm.js and check if the enter key was pressed and assume that the line the cursor was on at that time is the prompt line. Then you could read that line and try to parse the command that was executed. Still, it's very hard to tell when a program has finished running and you're back at the prompt. One way to detect that is to look at the last line of the terminal that has content, and then check if the cursor is in that line and the x coordinate is not 0. But there are many edge cases where this will fail.

[SterlingButters]

@mofux Thanks for your response

node-pty has absolutely no semantic knowledge of the data that is sent to or received from the pty.

This statement in itself is not really what I was suggesting. Having semantic knowledge of sent or received data presumably will not dictate how the data is sent/received.

How is it then that people can build these web terminals using node-pty and xterm.js with seemingly perfect emulation? Are they just handling every edge case with a hacky solution?

Specifically what comes to mind is handling nano, vim, etc. Surely people aren't doing the above?

[jerch]

How is it then that people can build these web terminals using node-pty and xterm.js with seemingly perfect emulation? Are they just handling every edge case with a hacky solution?

Specifically what comes to mind is handling nano, vim, etc. Surely people aren't doing the above?

The way unix/posix connects/interacts with a terminal is well defined and has matured over decades. Basically all programs follow the terminal interface with its escape sequences and the shell job control idea of a TTY. Its that simple - build these interfaces on emulator side and use the sequences on app - and you are ready to go.

[SterlingButters]

@jerch Sure enough I tried simplifying my code wayyy down and it works as it should now! I was making wayyy to many assumptions about the format of the data output by the pty and trying to handle that front-end