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

aj@exiledplanet.org aj at exiledplanet.org
Thu Jun 30 12:19:00 PDT 2005


Oh, wait a minute.  Did you say you tried the IPC::Session CPAN module?  The example it gives in its docs is similar to what you mentioned, but with ssh instead of telnet


--aj

"Metz, Bobby W, WCS" <bwmetz at att.com> wrote:
__________
>Yep, that's how I'd planned to launch it.  My users default to XTerm
>which isn't "colorful" on our boxen, so spawning a DTTerm does the
>trick.  I pretty much had it licked in expect but either couldn't get
>expect to print the remote device prompt in interact mode when matching
>against full line output and then when I did, expect wouldn't let the
>user input appear while waiting for a pattern match.  Appeared to be a
>buffering thing similar to Perl and I couldn't find info on it for
>Expect since the on-line resources for it are a bit thin and contrary to
>popular myth, the Don Libes "Exploring Expect" book by O'Reilly does NOT
>include the solution to every Expect issue, at least not in my opinion.
>I guess if I was a true Unix maven, I'd just write a Tcl/Tk solution.
>It'd be portable, but man I hated that stuff back in school.
>
>Bobby
>
>-----Original Message-----
>From: Scott Walters [mailto:scott at illogics.org]
>Sent: Thursday, June 30, 2005 10:12 AM
>To: Metz, Bobby W, WCS
>Cc: Victor Odhner; phoenix-pm at pm.org
>Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor
>
>
>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
>_______________________________________________
>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