[Phoenix-pm] Looking for ideas - Perl Telnet Monitor

[Victor Odhner]

Metz, Bobby W, WCS wrote:

>During the session I want to spawn other tools ...
>
I think you are stuck with having your client process every
byte of input that passes through. I've done that sort of thing
but always at the remote end, i.e., using "system" calls to the
system that my agent was running on. Doing it on the remote
host system is what IPC::Open2 seems to be about, but I gather
you want to run your client program on a local PC, and have it
participate in a dialog with a remotely-connected host.

You could write a client that accepts inputs from the user, and
if no special commands are recognized, just sends them on to
the telnet line. But it would scan the input line and if a special
command or macro were recognized, it could enter a dialog
either with the telnet session or with the user to execute special
functions. In some cases you might want two separate client
processes, one to send user input to the remote end, and another
to pass remote responses back to the user's screen. That is a
common design for "terminal emulator" type apps.

One trick in this process is that you need to know when you
have a prompt from the remote system, so you know when you
can send; but some of the time you won't care because you can
carry on a full-duplex conversation, using two separate (but
cooperating) processes, and send whenever you want to.

Something like this can't be fully general, since there will be
some program out there on the remote host that will produce
or expect a dialog that your program will manage to mess up.
But if you intend to control only a limited set of remote
operations, well, the fewer of them you want, the easier it
gets. For example, if you want to allow arbitrary command-line
operations but no screen-controlling software such as vi or
curses, then it can be really easy.

This can get tricky if the remote processes are trying to control
the screen -- either you have to make that totally transparent, or
you have to understand a fair amount of what's going on so you
won't mess up screen positioning and cursor control but still
can distinguish commands that should be handled by your client.

Operations like changing screen color, etc., if they were things
the remote system knew how to do, could be done by issuing
commands to that system and then passing back the formatted
results transparently; but otherwise, you could filter the stuff
received via telnet and superimpose your own formatting on it.
That's what a terminal emulator does on a PC when it's
presenting a terminal window combined with other objects on
the same screen, and maybe also watching for strings that
would prompt scripted responses by the client.

Finally, if it's OK for the user to be conscious of your client
sitting in the middle of the dialog, then the user can use special
commands or keystrokes to put your client into transparent
mode to run something like vi, and then back into participating
mode to use macro commands, switch among remote systems,
etc.

Good luck,

Vic