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

Metz, Bobby W, WCS bwmetz at att.com
Thu Jun 30 12:53:25 PDT 2005


First, appreciate everyone jumping on this.  I never expected so much
feedback.  Second, I was a bit too quick on my last e-mail.  Just
thought the single helper window should be simple enough.  Have the
parent proc spawn the XTerm then figure out the PTY device and open it
as a filehandle.  Instead of worry about interproc message passing for
child to tell parent what command user typed, I'll just begin by pattern
matching on the output since that's what my older scripts do anyway.
Especially seeing how Cisco devices allow just shortened command
notation.  I really wasn't looking forward to the multi-word, longest
match scenario.

Bobby

-----Original Message-----
From: phoenix-pm-bounces at pm.org [mailto:phoenix-pm-bounces at pm.org]On
Behalf Of Metz, Bobby W, WCS
Sent: Thursday, June 30, 2005 12:47 PM
To: Scott Walters; aj at exiledplanet.org
Cc: phoenix-pm at pm.org
Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor


Scott,
	I appreciated your insight nonetheless...made me realize how
little I know Perl ;-).  The Cookbook item Tom mentioned seems to meet
my need so far for matching IO.  I read it last night before e-mailing
the group but it didn't gel.  Once I get the STDOUT colorization done,
I'll tackle the user input matching.  Simple enough in the forked
client.  Fun part will be having the client spawn a second XTerm and
continue to update that XTerm with output from various subroutines based
on user input matches, but working against remote device output from the
parent process.  It's a telnet helper window or sorts.
	Ultimate goal is user types command (for you Cisco nerds, say
"show ip accounting").  Remote device output is printed to STDOUT on
parent process.  Helper window shows that output processed by some other
tools I've written in the past.  Users normally have to collect command
output to file and then manually run it tools against it.  This, I hope,
will allow live processing of output in the helper window based on
pattern matching user commands that I have tools for.  I guess step one
will be just to open a second XTerm every time a user command is
matched, then worry about the single window updating later.

Have I confused everyone yet?

Bobby

-----Original Message-----
From: phoenix-pm-bounces at pm.org [mailto:phoenix-pm-bounces at pm.org]On
Behalf Of Scott Walters
Sent: Thursday, June 30, 2005 12:32 PM
To: aj at exiledplanet.org
Cc: phoenix-pm at pm.org
Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor


No, I don't think I'm offering useful suggestions for the part he's
actually having
problems with.  Expect stuff I can't help with.  Left to myself with
this project,
I'd write the expect logic from scratch.  But I think I missed a message
or two.  I
don't even know where Expect is going wrong controlling the other
program, or
even what's being controlled.

-scott

On  0, aj at exiledplanet.org wrote:
> Aha!  A possible solution emerges!  Though I've forgotten what
coroutines are.  :-(
> 
> --aj
> 
> Scott Walters <scott at illogics.org> wrote:
> __________
> >Ahhh... okay, this is just a fragment, but it sounds like you're
having the 
> >standard problem of needing to monitor multiple IO handles -- in this
case, at
> >least one user and one program launched for the user by the daemon. 
> >
> >select() was designed for this, but it's painful for anything beyond
trivial
> >applications.  All operations must be atomic and must return back to
the
> >"select loop".  Hence things like POE were created.  POE also has an
event
> >loop which is little more than a select loop, but you're still
restricted
> >to atomic operations that can't block or perform additional IO
operations
> >in response to the one that just completed and must instead schedule
them
> >for the future.  You also don't get any variables that persist
between
> >these atomic operations -- all of your data must be instance data or
else
> >it's lost when you return back to the event handler.  This is only
marginally
> >better than a plain select loop.  Perl's threads are unusable for any
> >case where the threads must share data or else they'd get the
recommendation,
> >but for applications like this, I strongly advocate the Coro module.
In
> >fact, there are two chapters on it in _Perl 6 Now_ [blatent self-plug
> >alert].  
> >
> >Used like this, Coro provides essentially cooperative multithreading.
You'd 
> >still need IPC::Open2/IPC::Open3.  Coro has a method to convert
regular
> >file handles, such as those returned by IPC::Open2, into something
that knows
> >how to cede the CPU rather than block on data.  
> >
> >The structure would be something like this:  a listener loop accepts
connections
> >and creates a coroutine (the command prompt) for each connection
accepted.  The
> >command prompt accepts commands (obviously) and creates coroutines
for each
> >command that doesn't complete instantly.  These command coroutines
use 
> >IPC::Open2 or IPC::Open3 to open bi-directional or tri-directional
pipes to 
> >whichever system command is to be run (use the syntax that avoids
invoking the
> >shell!).  The command coroutines, after setting up the pipe, perform
filtering
> >on the data, applying any coloring or highlighting.  If a -more-
prompt is 
> >needed, a coroutine to manage (and filter) all of the command
coroutines
> >should be created.  Coro::Channel would be used to pass text,
objects, etc,
> >between coroutines, but ultimately, one coroutine (the command
prompt) would
> >be reading user input and one or more (the command coroutines or the 
> >command-coroutine-manager-coroutine) coroutines would write to the
user via
> >their socket.
> >
> >I hope this helps.  
> >
> >-scott
> >
> >On  0, "Metz, Bobby W, WCS" <bwmetz at att.com> wrote:
> >> Yeh, I was looking at the buffer stuff last night.  Believe expect
has a
> >> similar "problem"...that's why I canned that script...plus I hate
> >> expect. :)
> >> 
> >> -----Original Message-----
> >> From: Andrew Johnson [mailto:aj at exiledplanet.org]
> >> Sent: Wednesday, June 29, 2005 7:34 PM
> >> To: Metz, Bobby W, WCS
> >> Cc: phoenix-pm at pm.org
> >> Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor
> >> 
> >> 
> >> On Wed, 2005-06-29 at 19:54 -0500, Metz, Bobby W, WCS wrote:
> >> > [snip]
> >> > IO, i.e. it looks like regular send/expect stuff to me.  Anyone
out
> >> > there ever do anything like this or know of some easy Perl trick
to
> >> > monitor bi-dir IO on a TTY or Net:Telnet session without
completing
> >> > taking control from the user typing.  I'm sure the solution is
staring
> >> > me in the face, but right now it eludes me.
> >> 
> >> bidirectional IO that _doesn't_ take control from the user typing.
> >> Well, no.  But you might try IPC::Open2 (I suppose you could
capture
> >> your prog's STDIN and feed it to the telnet process, and pass back
> >> anything that is read from the telnet process's stdout handle).
Check
> >> out Chapter 16 (Interprocess Communcation), section 3.3
(Bidirectional
> >> Communication) of /Programming Perl/.  Since standard I/O buffering
is
> >> probably going to "ruin your day" (the Camel's quote), you might
also
> >> find IO::Select and the IO::Pty (avail on CPAN) module useful.
> >> 
> >> Hope this helps.
> >> 
> >> --aj
> >> 
> >> _______________________________________________
> >> 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