Detect console prompt in VT100 SSH Session stream

Question

I'm working on a wrapper library (in C#, but not really important to the issue here) to open an SSH connection and then allow for sending commands to the server and receiving the response. The main thing, however, is that I want to have the command call buffer the response stream and then return it all as one string to the user once the shell has returned to the console prompt. That way, I can just fire off a command and not have to deal with all the response events every time the server writes back to the console during the job.

So, my main question is, in a VT100 session, is there any fool-proof way of determining that the server has returned to the input prompt? The only thing I've found so far is that, with the two ssh servers I've tried (cygwin and Fedora), the last character sequence it always seems to output is '[esc][0m' [esc], being ASCII code 27 I would like to think that this is something standard, but when I looked up what that sequence is I found this:

modesoff SGR0, Turn off character attributes

I was kind of hoping for something more concrete, like "Waiting for input" :P

Any ideas if this should work for all/most systems? Or if there is a better way?

Answer 1

Character attributes, like bold, blinking, dim, underline, highlighted, etc. are all assigned numerical codes and can be chained together in an escape sequence to alter the display of text on the monitor.

The ESC [ 0 m sequence turns off all the settings, returning text to "normal," which is regular brightness and no other visual attributes.

The VT100 is merely displaying characters coming in on its serial port. So what constitutes a prompt is highly dependent on what you connect the terminal to, and most likely explains why you haven't gotten an answer.

Often systems that have prompts have user-customizable prompts, and it's likely that you can bake in a hidden sequence of characters, if not control characters, that you could then detect in your session.

Another way, though not as reliable, is to wait for a duration of inactivity from the host, which usually implies it's waiting for input (but not always).