expectperl-discuss Mailing List for Expect.pm

     I have an Expect perl application that accepts messages over the 
     network, and runs an interactive application with the data given.  It 
     opens up the process once and leaves it open.
     
     The problem I have is after running for a few days (usually between 2 
     days and a week), the opened process stops responding 
     ($process->expect(...) returns no data).  The process itself has not 
     died.  Any ideas what could be causing this?
     
     I'm using Expect 1.15 with IO::Tty 1.02.
     
     Previously I had this application running on Expect 1.10 with IO::Tty 
     0.04.  IO::Tty 0.04 was a pain to install on HP-UX and the only way I 
     could get it to work was to make it use /dev/tty instead of /dev/ptmx. 
      However, the app would run fine for months.  If there's a way I can 
     get this to work with the default installation of IO::Tty 1.02, that 
     would of course be much better for portability..
     
     Thanks,
     Aaron Brice
     ST Microelectronics

Hi,
=20
I am running into a few problems with Expect-1.15 on perl5.005. =
Specifically, I get "Error: could not connect pty as controlling =
terminal!" from time to time when trying to spawn a telnet to another =
machine.
I'm using FreeBSD 4.3 on i586.
As far as I can tell from digging a little in the Pty/Expect/Tty code as =
well as the kernel code, there's a problem with getting rid of =
controlling terminals on FreeBSD. Actually the sentence "Implement =
TIOCNOTTY or remove it from <sys/ioctl.h>" appears in the todo list in =
/src/sys/kern/tty.c on FreeBSD.
The problem as I can see it is in the following scenario:
1. in Expect->new, a pty is assigned
2. in spawn, Pty->make_slave_controlling_terminal is called
3. there it performs setsid()
4. afterwards it checks for the member {'io_pty_slave'} which was =
generated before, in the context of the previous session, and therefor =
the session struct in the kernel holds data about the previous session's =
controlling terminal
5. the call for TIOCSCTTY has the following code in it (tty.c):
                if (!SESS_LEADER(p) ||
                    ((p->p_session->s_ttyvp || tp->t_session) &&
                    (tp->t_session !=3D p->p_session)))
                        return (EPERM);
    where p is the proc structure, and tp is the tty structure (pointers =
ofcourse)
=20
Remembering that setsid() creates a new session context for the process =
and that tp might have had a controlling tty associated with it, =
problems may occur.
Btw, as I mentioned earlier TIOCNOTTY has not yet been implemented.
=20
I'm pretty sure that I haven't reached a full understanding in all of =
this, so any corrections would be very welcome.
=20
    Guy

On Sun, 26 May 2002 22:25:40 +0100
Stephen Quinney <st...@ja...> wrote:

> On Sat, May 25, 2002 at 03:01:26PM -0700, ex...@ih... wrote:
> 
> > On another topic I think that the case when $timeout is undef
> > isn't working properly.  i.e. I think it's getting defined
> > anyway but it's defined to the expect expression.  I think something is
> > getting shifted off but shouldn't be.  I was seeing under debug
> > that it was trying to subtract (line 612) using the expect string.
> 
> I wonder if what you are doing here is
> 
> $t->expect(,'-re',$pattern); 
> 
> or
> 
> $t->expect('-re',$pattern);
> 
> instead of 
> 
> $t->expect(undef,'-re',$pattern);

Sorry I missed this important distinction.  It says it right there
in the man page too....
Thanks.


> 
> if you want an undefined time out, i.e. it waits forever to match the
> pattern,  you need to state that specifically.
> 
> Stephen
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

On Sat, May 25, 2002 at 03:01:26PM -0700, ex...@ih... wrote:

> On another topic I think that the case when $timeout is undef
> isn't working properly.  i.e. I think it's getting defined
> anyway but it's defined to the expect expression.  I think something is
> getting shifted off but shouldn't be.  I was seeing under debug
> that it was trying to subtract (line 612) using the expect string.

I wonder if what you are doing here is

$t->expect(,'-re',$pattern); 

or

$t->expect('-re',$pattern);

instead of 

$t->expect(undef,'-re',$pattern);

if you want an undefined time out, i.e. it waits forever to match the
pattern,  you need to state that specifically.

Stephen

On Sat, 25 May 2002 22:40:29 +0200
Roland Giersig <RGi...@CP...> wrote:

> > Maybe I haven't framed the question properly.  But that might just be
> > that I don't understand the problem properly.  With debugging on and
> > $timeout not defined I get this
> > "Timed out waiting for an EOF from spawn id(6)"  and then it does a
> > hard close.
> 
> Oh, but this error message comes from soft_close(), so there already 
> was something unusual happening...

Yes I guess I'll keep digging around.

> 
> > I'm really pining for more examples of using this module, I saw kibitz
> > but there isn't much else.  I can read the docs until I'm blue but
> > I tend to benefit more from seeing things in action.
> 
> Sorry, there aren't really any, except those two in the FAQ.
> Maybe somebody
> would care to post some example code from their applications?
> Unfortunately

I've got one example another reader sent along for doing cisco stuff.
That helps.

On another topic I think that the case when $timeout is undef
isn't working properly.  i.e. I think it's getting defined
anyway but it's defined to the expect expression.  I think something is
getting shifted off but shouldn't be.  I was seeing under debug
that it was trying to subtract (line 612) using the expect string.

Thanks.

> Maybe I haven't framed the question properly.  But that might just be
> that I don't understand the problem properly.  With debugging on and
> $timeout not defined I get this
> "Timed out waiting for an EOF from spawn id(6)"  and then it does a
> hard close.

Oh, but this error message comes from soft_close(), so there already 
was something unusual happening...

> I'm really pining for more examples of using this module, I saw kibitz
> but there isn't much else.  I can read the docs until I'm blue but
> I tend to benefit more from seeing things in action.

Sorry, there aren't really any, except those two in the FAQ.  Maybe somebody 
would care to post some example code from their applications?  Unfortunately
I left my code at my previous employer...

Roland
--
RGi...@cp...

On Fri, 24 May 2002 09:48:33 +0200
RGi...@a1... wrote:

> > I'm running expect to talk to a script and I have the questions
> > (that the script asks) and the answers. I am running it inside a 
> > foreach loop based on number of questions/answers.  
> > 
> > Like so:
> > 
> > $exp = Expect->spawn('script');
> > 
> > foreach $qa (0..$#qaarray)
> > {
> > 	$exp->expect($timeout, $qaarray[$qa])
> > 	$exp->send($aarray[$qa]);
> > }
> > 
> > 
> > The time between when an answer is given and when a new
> > question is asked varies.  In some cases it may take an
> > hour and in others less than 1 second.  The problem I have
> > is that expect timesout and does a hard_close after some
> > amount of time. 
> 
> Yes, after the amount of time you specify in $timeout...
> 
> > I need it to wait for the next question
> > no matter how long it takes.  I've read the docs and tried
> > a lot of different things.  
> 
> Really?  So you obviously didn't notice this in the docs:
> 
>  "Given $timeout in seconds Expect will wait for $object's
>   handle to produce one of the match_patterns. Due to o/s
>   limitations $timeout should be a round number. If
>   $timeout is 0 Expect will check one time to see if
>   $object's handle contains any of the match_patterns. If
>   $timeout is undef Expect will wait forever for a pattern
>   to match."

Yes, saw this.
Maybe I haven't framed the question properly.  But that might just be
that I don't understand the problem properly.  With debugging on and
$timeout not defined I get this 
"Timed out waiting for an EOF from spawn id(6)"  and then it does a
hard close.

I'm really pining for more examples of using this module, I saw kibitz
but there isn't much else.  I can read the docs until I'm blue but
I tend to benefit more from seeing things in action. 

Thanks for any help.

> I'm running expect to talk to a script and I have the questions
> (that the script asks) and the answers. I am running it inside a 
> foreach loop based on number of questions/answers.  
> 
> Like so:
> 
> $exp = Expect->spawn('script');
> 
> foreach $qa (0..$#qaarray)
> {
> 	$exp->expect($timeout, $qaarray[$qa])
> 	$exp->send($aarray[$qa]);
> }
> 
> 
> The time between when an answer is given and when a new
> question is asked varies.  In some cases it may take an
> hour and in others less than 1 second.  The problem I have
> is that expect timesout and does a hard_close after some
> amount of time. 

Yes, after the amount of time you specify in $timeout...

> I need it to wait for the next question
> no matter how long it takes.  I've read the docs and tried
> a lot of different things.  

Really?  So you obviously didn't notice this in the docs:

 "Given $timeout in seconds Expect will wait for $object's
  handle to produce one of the match_patterns. Due to o/s
  limitations $timeout should be a round number. If
  $timeout is 0 Expect will check one time to see if
  $object's handle contains any of the match_patterns. If
  $timeout is undef Expect will wait forever for a pattern
  to match."

Hope this helps,

Roland
--
RGi...@cp...

I'm running expect to talk to a script and I have the questions
(that the script asks) and the answers. I am running it inside a foreach loop
based on number of questions/answers.  

Like so:

$exp = Expect->spawn('script');

foreach $qa (0..$#qaarray)
{
	$exp->expect($timeout, $qaarray[$qa])
	$exp->send($aarray[$qa]);
}


The time between when an answer is given and when a new
question is asked varies.  In some cases it may take an
hour and in others less than 1 second.  The problem I have
is that expect timesout and does a hard_close after some
amount of time.  I need it to wait for the next question
no matter how long it takes.  I've read the docs and tried
a lot of different things.  

=3E I have a first perl/expect script attempt going=2E  I have the main
=3E structure and loop set up=2E  It=27s working fine=2E  I=27m trying to=
 ssh =

=3E to a remote server to execute a command=2E  I then want to funnel
=3E the output back to an array=2E
=3E =

=3E Does anyone have anything similar I can take apart and learn from=3F =

=3E A couple of the problems I=27m hitting=2E  How do I turn off echo fro=
m my
=3E spawn commands=3F  How do I shove my output back into my array=3F  I=27=
m not
=3E seeing a method for this=2E

First=2C have you noted the following two FAQs=3F

  I want to automate password entry for su/ssh/scp/rsh/=2E=2E=2E

    You shouldn=27t use Expect for this=2E  Putting passwords=2C
    especially root passwords=2C into scripts in clear text can
    mean severe security problems=2E  I strongly recommend using
    other means=2E  For =27su=27=2C consider switching to =27sudo=27=2C w=
hich
    gives you root access on a per-command and per-user basis
    without the need to enter passwords=2E  =27ssh=27/=27scp=27 can be se=
t
    up with RSA authentication without passwords=2E  =27rsh=27 can use
    the =2Erhost mechanism=2C but I=27d strongly suggest to switch to
    =27ssh=27=3B to mention =27rsh=27 and =27security=27 in the same sent=
ence
    makes an oxymoron=2E
     It will work for =27telnet=27=2C though=2C and there are valid uses
    for it=2C but you still might want to consider using =27ssh=27=2C as
    keeping cleartext passwords around is very insecure=2E

  I want to use Expect to automate =5Banything with a buzzword=5D=2E=2E=2E=


    Are you sure there is no other=2C easier way=3F  As a rule of
    thumb=2C Expect is useful for automating things that expect to
    talk to a human=2C where no formal standard applies=2E  For
    other tasks that do follow a well-defined protocol=2C there
    are often better-suited modules that already can handle
    those protocols=2E  Don=27t try to do HTTP requests by spawning
    telnet to port 80=2C use LWP instead=2E  To automate FTP=2C take a
    look at the Net=3A=3AFTP manpage or =22ncftp=22
    (http=3A//www=2Encftp=2Eorg)=2E  You don=27t use a screwdriver to
    hammer in your nails either=2C or do you=3F


So=2C how about using =27=24output =3D qx(ssh =24host =24command)=27=3F

The Expect manpage contains a source example how to automate telnet =

login=2C which might be of interest=2E  See also the entry for =27log=5Ff=
ile=27=2E  =

Apart from that=2C how about matching line for line and stuffing that =

into an array=3F  E=2Eg=2E

=24exp-=3Eexpect(=24timeout=2C =5B qr/=2E*=5Cn/ =3D=3E sub =7B my =24self=
 =3D shift=3B push =

=40array=2C =24self-=3Ematch()=3B exp=5Fcontinue=3B =7D =5D)=3B

Hope this helps=2C

Roland
--
RGiersig=40cpan=2Eorg

----- Urspr=FCngliche Nachricht -----
Von=3A =22Robert L=2E Harris=22 =3CRobert=2EL=2EHarris=40rdlg=2Enet=3E
Datum=3A Dienstag=2C Mai 21=2C 2002 6=3A50 pm
Betreff=3A =5BExpectperl-discuss=5D New Script

=3E =

=3E =

=3E First post=2C hopefully on topic=2E
=3E =

=3E =

=3E =

=3E =3Awq!
=3E -------------------------------------------------------------------
=3E --------
=3E Robert L=2E Harris                =7C  Micros=7E1 =3A
=3E Senior System Engineer          =7C    For when quality=2C reliabilit=
y
=3E  at RnD Consulting             =7C      and security just aren=27t
=3E                                =5C=5F       that important!
=3E DISCLAIMER=3A
=3E      These are MY OPINIONS ALONE=2E  I speak for no-one else=2E
=3E FYI=3A
=3E perl -e =27print =24i=3Dpack(c5=2C(41*2)=2Csqrt(7056)=2C(unpack(c=2CH=
)-
=3E 2)=2Coct(115)=2C10)=3B=27
=3E =

=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E =

=3E Don=27t miss the 2002 Sprint PCS Application Developer=27s Conference=

=3E August 25-28 in Las Vegas -- http=3A//devcon=2Esprintpcs=2Ecom/adp/in=
dex=2Ecfm
=3E =

=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Expectperl-discuss mailing list
=3E Expectperl-discuss=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/expectperl-discuss=

=3E 

First post, hopefully on topic.

I have a first perl/expect script attempt going.  I have the main
structure and loop set up.  It's working fine.  I'm trying to ssh to a
remote server to execute a command.  I then want to funnel the output
back to an array.

Does anyone have anything similar I can take apart and learn from?  A
couple of the problems I'm hitting.  How do I turn off echo from my
spawn commands?  How do I shove my output back into my array?  I'm not
seeing a method for this.


:wq!
---------------------------------------------------------------------------
Robert L. Harris                |  Micros~1 :
Senior System Engineer          |    For when quality, reliability
  at RnD Consulting             |      and security just aren't
                                \_       that important!
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.
FYI:
 perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

On Fri, May 17, 2002 at 01:37:33PM -0700, Syamala Tadigadapa wrote:
> I have made significant improvement from 24hrs to 4.5hrs. by
> clearing accumulator after every time out of  15sec. It could make
> more saving if I set the time out to say 3 seconds or so. Now then,
> I have still the CPU monopolization occurring of course. As suggested,
> I am going to try set the Exp_Max_Accum to 8096.  I can reports my
> findings once I see them. I have the following questions.
> 
> 1.  Why can't I have a method in Expect which can allow me to
>       truncate the accumulator to the point of pattern matching. If
>       present, I could simply call the method once I find a match.
>       This could prevent the buffer/accumulator from choking.
> 2.   Expect can trim the accumulator at each each match to a
>       configurable size, say a default of 4k. This should be done
>       evenly at time out points also. This could as well prevent
>       accumulator/buffer from choking.

	The accumulator should be clearing by itself after every successful
match, not including timeout.

	8096 is the maximum number of bytes that can be read at one time
in the current implementation. I would suggest a slightly _larger_ number
for the possibility that you will have a pattern match that occurs right at
the border between the last read and the current one.
	If you are having high CPU utilization after you set max accum, I
would guess that you are probably seeing many small reads very close together
in time rather than one big one, forcing the expect matching engine into
action each time. If this is indeed the case it might be possible to
put small delays inside the expect matching loop to force it to read
in larger chunks.
	Please let us know how it goes.

	Thanks,

	Austin
	

I have made significant improvement from 24hrs to 4.5hrs. by
clearing accumulator after every time out of  15sec. It could make
more saving if I set the time out to say 3 seconds or so. Now then,
I have still the CPU monopolization occurring of course. As suggested,
I am going to try set the Exp_Max_Accum to 8096.  I can reports my
findings once I see them. I have the following questions.

1.  Why can't I have a method in Expect which can allow me to
      truncate the accumulator to the point of pattern matching. If
      present, I could simply call the method once I find a match.
      This could prevent the buffer/accumulator from choking.
2.   Expect can trim the accumulator at each each match to a
      configurable size, say a default of 4k. This should be done
      evenly at time out points also. This could as well prevent
      accumulator/buffer from choking.

By the way, I found another machine, which is NOT Linux also
hit by the same issue. So, it is not Linux specific problem.

-Syamal.
---------

Austin Schutz wrote:

> On Tue, May 14, 2002 at 06:04:28PM -0700, Syamala Tadigadapa wrote:
> > I have an in house perl application that uses Expect to tail to a legacy
> > program.
> > I have it run satisfactorily on multiple platforms.
> >
> > On linux platforms, I have sean a strange problem. The perl executable
> > monopolizing
> > a cpu after a while of execution time. The legacy program is too
> > loquacious and writes
> > a lot of stuff on the STDOUT.  Perhaps thousands of lines are being
> > shown on STDOUT.
> >
> > The program is running correctly, but unbearably slow!  Slow over 10
> > times or worse.
> >
>
>         Expect by default will match the entire output for a match everytime
> more output is created by the spawned program. If you have a verbose program
> that doesn't match it becomes difficult for perl to keep up. Typically the
> answer is to set max_accum() to some sane value, perhaps 10000. What can go
> wrong is if you set the max value to less than what is read you may lose
> matching data.
>         Currently expect will read up to 8096 bytes at a time from a
> stream.  Hmm, maybe it would make sense to make this some fraction of
> exp_Max_Accum. Alternately maybe it would make sense to trim exp_Accum _after_
> the pattern matches rather than before.
>
>         Austin

Is this verbose output from the legacy program specific to the Linux environment?    Not.
What is being done with the output on a match, is it maintained or discarded?        Discard.
[ Do I need to any special action to clear the accumulating output from the program spawned by Expect?
After a match I usually take some action like saving matched pattern in an array, responding toprogram with some string etc. ]

 What is the memory utilization compared to the other platforms?  
I have notmade any measurements and/or comparisons against any other platform. Everywhere elese, the application is
behaving normally.
The only platform specific problems we've had with Expect.pm under Linux was a process count utilization.

Can it cause the perl executable to monopolize one of the CPUs?  Can you please educate me on this process
count utilization.



: From: Syamala Tadigadapa [mailto:sya...@or...]
: 
: On linux platforms, I have sean a strange problem. The perl executable
: monopolizing
: a cpu after a while of execution time. The legacy program is too
: loquacious and writes
: a lot of stuff on the STDOUT. Perhaps thousands of lines are being
: shown on STDOUT.

Is this verbose output from the legacy program specific to the Linux environment? What is being done with the output on a match, is it maintained or discarded? What is the memory utilization compared to the other platforms? The only platform specific problems we've had with Expect.pm under Linux was a process count utilization.

Mark

--
[] Mark Rogaski "Computers save time like 
[] AT&T Frame Relay Service kudzu prevents soil erosion"
[] email: ro...@at... -- Al Castanoli
[] voice: 732-885-7534 fax: 732-885-7699
[] pager: 888-858-7243 pin 200853 or 20...@pa... 

On Tue, May 14, 2002 at 06:04:28PM -0700, Syamala Tadigadapa wrote:
> I have an in house perl application that uses Expect to tail to a legacy
> program.
> I have it run satisfactorily on multiple platforms.
> 
> On linux platforms, I have sean a strange problem. The perl executable
> monopolizing
> a cpu after a while of execution time. The legacy program is too
> loquacious and writes
> a lot of stuff on the STDOUT.  Perhaps thousands of lines are being
> shown on STDOUT.
> 
> The program is running correctly, but unbearably slow!  Slow over 10
> times or worse.
> 

	Expect by default will match the entire output for a match everytime
more output is created by the spawned program. If you have a verbose program
that doesn't match it becomes difficult for perl to keep up. Typically the
answer is to set max_accum() to some sane value, perhaps 10000. What can go
wrong is if you set the max value to less than what is read you may lose
matching data.
	Currently expect will read up to 8096 bytes at a time from a
stream.  Hmm, maybe it would make sense to make this some fraction of
exp_Max_Accum. Alternately maybe it would make sense to trim exp_Accum _after_
the pattern matches rather than before.

	Austin

Make that: a process count limitation.

Mark

--
[] Mark Rogaski                    "Computers save time like=20
[] AT&T Frame Relay Service           kudzu prevents soil erosion"
[] email: ro...@at...                          -- Al Castanoli
[] voice: 732-885-7534 fax: 732-885-7699
[] pager: 888-858-7243 pin 200853 or 20...@pa...=20


: -----Original Message-----
: From: Rogaski, Mark, ALCNS=20
: Sent: Tuesday, May 14, 2002 9:34 PM
: To: Syamala Tadigadapa; exp...@li...
: Subject: RE: [Expectperl-discuss] Expect on linux monopolizes cpu!
:=20
:=20
: : From: Syamala Tadigadapa [mailto:sya...@or...]
: :=20
: : On linux platforms, I have sean a strange problem. The perl=20
: executable
: : monopolizing
: : a cpu after a while of execution time. The legacy program is too
: : loquacious and writes
: : a lot of stuff on the STDOUT.  Perhaps thousands of lines are being
: : shown on STDOUT.
:=20
: Is this verbose output from the legacy program specific to=20
: the Linux environment?  What is being done with the output on=20
: a match, is it maintained or discarded?  What is the memory=20
: utilization compared to the other platforms?  The only=20
: platform specific problems we've had with Expect.pm under=20
: Linux was a process count utilization.
:=20
: Mark
:=20
: --
: [] Mark Rogaski                    "Computers save time like=20
: [] AT&T Frame Relay Service           kudzu prevents soil erosion"
: [] email: ro...@at...                          -- Al Castanoli
: [] voice: 732-885-7534 fax: 732-885-7699
: [] pager: 888-858-7243 pin 200853 or 20...@pa...=20
:=20
:=20
: _______________________________________________________________
:=20
: Have big pipes? SourceForge.net is looking for download=20
: mirrors. We supply
: the hardware. You get the recognition. Email Us:=20
: ban...@so...
: _______________________________________________
: Expectperl-discuss mailing list
: Exp...@li...
: https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
:=20

: From: Syamala Tadigadapa [mailto:sya...@or...]
:=20
: On linux platforms, I have sean a strange problem. The perl executable
: monopolizing
: a cpu after a while of execution time. The legacy program is too
: loquacious and writes
: a lot of stuff on the STDOUT.  Perhaps thousands of lines are being
: shown on STDOUT.

Is this verbose output from the legacy program specific to the Linux =
environment?  What is being done with the output on a match, is it =
maintained or discarded?  What is the memory utilization compared to the =
other platforms?  The only platform specific problems we've had with =
Expect.pm under Linux was a process count utilization.

Mark

--
[] Mark Rogaski                    "Computers save time like=20
[] AT&T Frame Relay Service           kudzu prevents soil erosion"
[] email: ro...@at...                          -- Al Castanoli
[] voice: 732-885-7534 fax: 732-885-7699
[] pager: 888-858-7243 pin 200853 or 20...@pa...=20

I have an in house perl application that uses Expect to tail to a legacy
program.
I have it run satisfactorily on multiple platforms.

On linux platforms, I have sean a strange problem. The perl executable
monopolizing
a cpu after a while of execution time. The legacy program is too
loquacious and writes
a lot of stuff on the STDOUT.  Perhaps thousands of lines are being
shown on STDOUT.

The program is running correctly, but unbearably slow!  Slow over 10
times or worse.

The Expect module was Expect 1.12, when problem was discovered.

I have switched from  Expect 1.12 to the latest Expect 1.15. Problem
persists.

[ Basically the perl application uses expect to match from a hoard of
patterns (about 60)
in a loop. ]

Does some body has a clue as to what is going on?

-Syamal.
-----------

> I am using Expect 1.15 on the Perl for Cygwin release 5.6.1-2. I 
> want to use Expect with SSH2 to automate some commands that I have to 
do 
> regularly on remote servers.

First of all, please note the following FAQs from Expect:

  I want to automate password entry for su/ssh/scp/rsh/...

  You shouldn't use Expect for this.  Putting passwords,
  especially root passwords, into scripts in clear text can
  mean severe security problems.  I strongly recommend using
  other means.  For 'su', consider switching to 'sudo', which
  gives you root access on a per-command and per-user basis
  without the need to enter passwords.  'ssh'/'scp' can be set
  up with RSA authentication without passwords.  'rsh' can use
  the .rhost mechanism, but I'd strongly suggest to switch to
  'ssh'; to mention 'rsh' and 'security' in the same sentence
  makes an oxymoron.
  It will work for 'telnet', though, and there are valid uses
  for it, but you still might want to consider using 'ssh', as
  keeping cleartext passwords around is very insecure.


  I want to use Expect to automate [anything with a buzzword]...

  Are you sure there is no other, easier way?  As a rule of
  thumb, Expect is useful for automating things that expect to
  talk to a human, where no formal standard applies.  For
  other tasks that do follow a well-defined protocol, there
  are often better-suited modules that already can handle
  those protocols.  Don't try to do HTTP requests by spawning
  telnet to port 80, use LWP instead.  To automate FTP, take a
  look at the Net::FTP manpage or "ncftp"
  (http://www.ncftp.org).  You don't use a screwdriver to
  hammer in your nails either, or do you?


> But so far I have not been able to do this properly. I am using F-
> Secure SSH for Windows, maybe this causes some trouble?

Definitely, you shouldn't mix native Windows applications with Cygwin.  
Use the 'ssh' from Cygwin instead.

> With F-Secure SSH2, I am not 
> able to give any parameter to the process, and with a sftp2 from 
> SSH, the password is entered succesfully by the script after catching 
the 
> password prompt, but then I can't do anything else, as Expect doesn't 
seem 
> to catch the prompt given by sftp2.
> 
> Some other tests seem to show that I have the same problem when 
> using ftp. 

Again, always use Cygwin applications.  Expect cannot deal with native 
Windows applications, the underlying model is too different.  That's 
why there is not native Windows version of IO-Tty, which Expect builds 
upon.

I'd recommend you look into RSA authentication without passphrase to 
automate your remote commands without the need to enter a password.  
Then you probably don't need Expect, a simple

 $output = qx(ssh $remote_host $command);

or similar system() call should suffice.  Expect is very useful if you 
have to emulate a human at the keyboard, for other tasks it's just 
overkill.

Hope this helps,

Roland
--
RGi...@cp...

Hello,

I am using Expect 1.15 on the Perl for Cygwin release 5.6.1-2. I want to use 
Expect with SSH2 to automate some commands that I have to do regularly on 
remote servers.

But so far I have not been able to do this properly. I am using F-Secure SSH 
for Windows, maybe this causes some trouble? With F-Secure SSH2, I am not 
able to give any parameter to the process, and with a sftp2 from SSH, the 
password is entered succesfully by the script after catching the password 
prompt, but then I can't do anything else, as Expect doesn't seem to catch 
the prompt given by sftp2.

Some other tests seem to show that I have the same problem when using ftp. 
The prompt is shown on the screen, but Expect won't catch it.

Is this a known issue?? I'm getting quite desperate.

Here is my very simple sample script:

----------------------------------------------------------

#! /usr/bin/perl -w

use Expect

$Expect::Log_Stdout=1;
$Expect::Exp_Internal=1;

my $cmd="/path/sftp2 -P port user\@IP.IP.IP.IP";

my $process = new Expect;
$process->raw_pty(1);
$process->spawn($cmd);
$process->expect(10, "word: ");
$process->send("mypassword\n");
$process->expect(10, "sftp>");      # here, sftp> appears on the screen, but 
isn't read by Expect
$process->send("ls\n");             # consequently, ls\n is written after 
the timeout occurs, but there is no reaction from sftp. Moreover, if I type 
the ls command by hand on the keyboard, it'll work
$process->expect("sftp>");



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Hello,

I'm using cpan to "install Bundle::Expect" and get the following error - a
complaint about the version of IO::Pty.  I'm expecting an install error
because I don't have permission to write to the /usr/local/lib directories
on this box - I was going to "make install" after edit'ing the Makefile so
that it would install in my directory.  Can I fix this?

Thanks,

Warren

-------------[ partial output of "install Bundle::Expect" ]------------

  CPAN.pm: Going to build R/RG/RGIERSIG/Expect-1.15.tar.gz

mkdir blib
mkdir blib/lib
mkdir blib/arch
mkdir blib/arch/auto
mkdir blib/arch/auto/Expect
mkdir blib/lib/auto
mkdir blib/lib/auto/Expect
cp Expect.pod blib/lib/Expect.pod
cp Expect.pm blib/lib/Expect.pm
  /sbin/make  -- OK
Running make test
        PERL_DL_NONLAZY=1
/usr/sbin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/perl56/5.6.0/irix-n32
-mips3 -I/usr/local/lib/perl56/5.6.0 test.pl
1..36
IO::Pty version 0.97 required--this is only version 0.01 at
blib/lib/Expect.pm line 22.
BEGIN failed--compilation aborted at blib/lib/Expect.pm line 22.
Compilation failed in require at test.pl line 27.
BEGIN failed--compilation aborted at test.pl line 27.
*** Error code 255 (bu21)
  /sbin/make test -- NOT OK