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

Scott Walters scott at illogics.org
Thu Jun 30 10:12:11 PDT 2005


I was assuming colorizing would happen in the original xterm.  It would 
certainly be possible to create invoke xterms with a -display of whereever
the user is at and to run a program inside of that xterm, but to run that
program in a "wrapper" that colorizes its output.  Then the daemon
program might be doing something like...

   system 'xterm', '-display', $calling_host.':0.0', '-e', 
       "goof_ball_wrapper.pl $actual_program_to_launch_in_xterm";

goof_ball_wrapper.pl would run whichever program was meant to be in the
xterm. It would use IPC::Open2 and then either fork(), use POE, use threads,
or use Coro to, both at the same time, listen for user input on STDIN, and to 
listen for output to the user from the pipe opened by IPC::Open2.  Then it's
just a matter of filtering data as it's copied.

-scott

On  0, "Metz, Bobby W, WCS" <bwmetz at att.com> wrote:
> Ah, to clarify a bit...
> 
> Users all telnet from local server to remote devices.
> User interface is X-Term from local server.
> Certain user commands on remote device will be matched to kick-off other
> scripts, output to be displayed in second X-Window opened for that
> purpose.
> Certain remote device responses return via telnet to user will have
> X-Term control sequences added to highlight or colorize certain
> keywords.
> 
> Hope that clarifies things a bit.  I wasn't real clear last night.
> 
> Bobby
> 
> 
> -----Original Message-----
> From: phoenix-pm-bounces at pm.org [mailto:phoenix-pm-bounces at pm.org]On
> Behalf Of Scott Walters
> Sent: Wednesday, June 29, 2005 11:27 PM
> To: Victor Odhner
> Cc: phoenix-pm at pm.org
> Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor
> 
> 
> Hi,
> 
> I'm not in any condition to really comment on this, but being
> an old MUD player, I've seen a goodly number of telnet emulators
> written -- and MUD "front end" clients written. "telnet" has its
> own RFC describing operations (negotiate about window size, etc).
> It seems like you either want to implement the RFC with a 
> front end or else you're really trying to do something more
> interesting. But I'm not clear on which case is the case.
> 
> -scott
> 
> On  0, Victor Odhner <vodhner at cox.net> wrote:
> > 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
> > 
> > _______________________________________________
> > Phoenix-pm mailing list
> > Phoenix-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/phoenix-pm
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm


More information about the Phoenix-pm mailing list