expectperl-discuss — Discussions about Perl modules Expect.pm, IO::Tty and IO::Stty

RE: [Expectperl-discuss] Expect and CGI

[Blackstone, J. D. <jda...@ci...>]

  Try setting the $| variable.  Mixing output of different programs in your
STDOUT stream can cause them to come out in different orders because of
buffering.

  Alternatively, try storing the output of ls yourself in a variable and
outputting it in the proper sequence.

jdb
-----Original Message-----
From: Todd Rosenberry [mailto:ros...@xi...]
Sent: Tuesday, January 15, 2002 6:33 PM
To: exp...@li...
Subject: [Expectperl-discuss] Expect and CGI


  
    I'm am trying to use Expect in a CGI program and am having strange
results.  Here is a very much stripped down version of my code.  It is just
for example purposes.  I would expect to get a page with a "Go" button and
when I press it I would see 
staring spawn (ls) 
spawn done 
Listing: <listing> 
<GO> 
instead I see 
staring spawn (ls) 
Content-type: text/html staring spawn (ls) 
spawn done 
Listing: <listing> 
<GO> 
Its like the whole program is starting over the first time  it sees the
spawn line but the command is only being executed once.   Any idea what's
going on? 
#!/var/yp/bin/perl 
use CGI; 
use Expect; 
$Expect::Log_Stdout=0; 
$query = new CGI; 
$formAction=$query->url(); 
$action=$query->param('action'); 
print "Content-type: text/html\n\n"; 
if ($action eq "Go") { 
   $cmd="ls"; 
   print "spawn starting ($cmd)<BR>\n"; 
   $run = Expect->spawn("$cmd"); 
   print "spawn done<BR>\n"; 
   $run->expect(10,'-re','.*'); 
   print "Listing: " . $run->match(). "<BR>\n"; 
}; 
print "<BR><FORM action=$formAction METHOD=post>\n"; 
print "<INPUT TYPE=submit name=action value=Go><BR><BR>\n"; 
- Todd 

[Expectperl-discuss] Expect and CGI

[Todd R. <ros...@xi...>]

    I'm am trying to use Expect in a CGI program and am having strange
results.  Here is a very much stripped down version of my code.  It is
just for example purposes.  I would expect to get a page with a "Go"
button and when I press it I would see

staring spawn (ls)
spawn done
Listing: <listing>
<GO>

instead I see

staring spawn (ls)
Content-type: text/html staring spawn (ls)
spawn done
Listing: <listing>
<GO>

Its like the whole program is starting over the first time  it sees the
spawn line but the command is only being executed once.   Any idea
what's going on?

#!/var/yp/bin/perl

use CGI;
use Expect;

$Expect::Log_Stdout=0;
$query = new CGI;

$formAction=$query->url();
$action=$query->param('action');

print "Content-type: text/html\n\n";

if ($action eq "Go") {
   $cmd="ls";
   print "spawn starting ($cmd)<BR>\n";
   $run = Expect->spawn("$cmd");
   print "spawn done<BR>\n";
   $run->expect(10,'-re','.*');
   print "Listing: " . $run->match(). "<BR>\n";
};

print "<BR><FORM action=$formAction METHOD=post>\n";
print "<INPUT TYPE=submit name=action value=Go><BR><BR>\n";

- Todd

Re: [Expectperl-discuss] Beginner Questions: Reference & How to Handle Large Output

[<RGi...@a1...>]

> I know exactly which line of Perl I'm on.  It's the expect() call 
> that is waiting for the command output to get all transferred.

But it might be interesting where the time is spent within expect()... 

> Yes, this is the approach I decided to take and it works fine.  I 
> postedthe question in order to understand what Expect was doing 
> under the covers,
> why it was so slow, and whether or not there was anything I could 
> tweak to
> speed things up.  Yes, I can code around it, but this provides me a
> learning opportunity to better understand Expect.  Also to find better
> learning material.

Sorry about the learning material.  The nice thing about Perl is, if 
everything else fails: "Read the source, Luke!"  ;-)

[but don't take the Expect code as a guideline how to program in perl, 
it's really a mess and I'm planning a complete rewrite]

Coming back to your problem:  Expect should only be used for 
applications where you have to send different input in response to 
variable output, i.e. for interactive applications.  If you can do the 
job in a shell script, then Expect is overkill.  You don't use a 
screwdriver to hammer in your nails either, right? :-)

In most cases, setting up ssh with RSA keys allows to transparently do 
the things you want.  If you use Expect for password entry, think 
again.  It's not secure to store passwords in the clear and there are 
very few cases where this is appropriate.

Why Expect is slow:  it's never been intended for speed applications, 
its sole purpose is to obviate the need for user interaction.  
Internally it does a select(), reads in chunks from its various data 
sources into accumulators (possibly truncating them) and does the 
pattern matching on them.

> I agree, and that's what I am doing, but I'd still like to know if 
> there'sanything I can do to speed up Expect's data collection.  It 
> sounds like no, there isn't.

Not without a substantial rewrite.  There are plans by Don Libes to do 
a complete rewrite of the original expect so that it can be used with 
various scripting languages, and that version certainly would have a 
better performance, but still:  use the right tool for the job.

Feel free to ask if you want further details about Expects innards.

Hope this helps,

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

[Expectperl-discuss] Beginner Questions: Reference & How to Handle Large Output

[Rick_Jasper/Delphion%<DEL...@de...>]

David Blackstone wrote,
>>  If you have the third edition camel, look up the command for how to
>> profile your code.  I believe it involves running a command called
dprofpp ...

I know exactly which line of Perl I'm on.  It's the expect() call that is
waiting for the command output to get all transferred.

Roland Giersig wrote,
>> Ugh, and there is no other way to do that?  Is it really an interactive
>> application?  How about just doing a ssh command and capture the
>> output?  Or having the remote system dump that data to a disk and then
>> transfer that with scp?

Yes, this is the approach I decided to take and it works fine.  I posted
the question in order to understand what Expect was doing under the covers,
why it was so slow, and whether or not there was anything I could tweak to
speed things up.  Yes, I can code around it, but this provides me a
learning opportunity to better understand Expect.  Also to find better
learning material.

>> That's no wonder.  Expect keeps a buffer for matching, and if you
>> do not set max_match ...
I tried setting max_match to 600MB.  It didn't help at all.  Even if I
wasn't trying to match anything, the data transfer was very slow.

>> IMHO your best bet is to change the approach to the problem, see my
suggestions above.
I agree, and that's what I am doing, but I'd still like to know if there's
anything I can do to speed up Expect's data collection.  It sounds like no,
there isn't.

Rick Jasper

RE: [Expectperl-discuss] Beginner Questions: Reference & How to H andle Large Output

[Blackstone, J. D. <jda...@ci...>]

> -----Original Message-----
> From: RGi...@a1... [mailto:RGi...@a1...]
> Sent: Thursday, January 10, 2002 10:30 AM
> To: Rick_Jasper/Delphion%DEL...@de...
> Cc: exp...@li...
> Subject: Re: [Expectperl-discuss] Beginner Questions: 
> Reference & How to
> Handle Large Output
> 
> 
> > I've got Expect 1.12 on an AIX 4.3.3 system, trying to figure out 
> > how best
> > to use it to ssh to some other system overseas, run a 
> command on that
> > oversea system that produces a lot of output (1.5 million lines, 
> > 136 MB
> > total), collect and process that output on my system.
> 
> Ugh, and there is no other way to do that?  Is it really an 
> interactive 
> application?  How about just doing a ssh command and capture the 
> output?  Or having the remote system dump that data to a disk 
> and then 
> transfer that with scp?

  To be specific, Rick, you should be able to:

$ ssh remote-host remote-command args > localfile

  You might look into ssh key generation to eliminate the need for a
password.  I recommend the O'Reilly snail book, as well as some articles by
the creator of Gentoo Linux on IBM developer works (you'll want to do a
google search; it always takes me forever to find those articles when I need
them).

  You can system() from Perl to call the ssh if you need this to be part of
a larger program.  There's also a Net::SSH::Perl module that can do the ssh
protocol itself, without the overhead of calling a separate command.  (I
think.)  You could even
open $fh, "ssh remote-host remote-command args |" || die...

  Of course, if this is a screen-oriented (curses?) interface you're using
on the remote system, you might not be able to do any of this.  That's my
plight.

jdb

Re: [Expectperl-discuss] Beginner Questions: Reference & How to Handle Large Output

[<RGi...@a1...>]

> I've got Expect 1.12 on an AIX 4.3.3 system, trying to figure out 
> how best
> to use it to ssh to some other system overseas, run a command on that
> oversea system that produces a lot of output (1.5 million lines, 
> 136 MB
> total), collect and process that output on my system.

Ugh, and there is no other way to do that?  Is it really an interactive 
application?  How about just doing a ssh command and capture the 
output?  Or having the remote system dump that data to a disk and then 
transfer that with scp?

> When I ssh to the remote system and run the command manually, the 1.5
> million lines scrolls past my screen in 46 minutes (that's 32,000
> lines/minute).  But when I use Expect to login, run the command 
> and capture the output, it takes forever!

That's no wonder.  Expect keeps a buffer for matching, and if you
do not set max_match, this buffer will not truncate lest there is a 
match.  Even if you match each line, there is still a lot of overhead, 
Expect reading in chunks of text and doing matches on them, copying 
around things etc.

IMHO your best bet is to change the approach to the problem, see my 
suggestions above.  Maybe if you can explain in more depth what you are 
trying to do and the background and limitations you are trying to 
overcome?

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

RE: [Expectperl-discuss] Beginner Questions: Reference & How to H andle Large Output

[Blackstone, J. D. <jda...@ci...>]

  If you have the third edition camel, look up the command for how to
profile your code.  I believe it involves running a command called dprofpp.
This will show you the time your program spends in each subroutine so you
can find out what is really taking so long.  Then you can zero in on that
routine.

jdb

> -----Original Message-----
> From: Rick_Jasper/Delphion%DEL...@de...
> [mailto:Rick_Jasper/Delphion%DEL...@de...]
> Sent: Wednesday, January 09, 2002 6:41 PM
> To: exp...@li...
> Subject: [Expectperl-discuss] Beginner Questions: Reference & How to
> Handle Large Output
> 
> 
> Where's the best how-to/tutorial reference for Expect under Perl for
> beginners?  I have the Exploring Expect and Perl books, but 
> the Expect book
> is difficult to digest and the Perl books don't have much on 
> Expect.  I'm
> looking for good, detailed examples of using the Perl/Expect 
> module, not
> the Tcl/Expect, aimed at the novice.  The pod is sparse and 
> presumes more
> Perl and Expect experience than I have.
> 
> I've got Expect 1.12 on an AIX 4.3.3 system, trying to figure 
> out how best
> to use it to ssh to some other system overseas, run a command on that
> oversea system that produces a lot of output (1.5 million 
> lines, 136 MB
> total), collect and process that output on my system.
> 
> When I ssh to the remote system and run the command manually, the 1.5
> million lines scrolls past my screen in 46 minutes (that's 32,000
> lines/minute).  But when I use Expect to login, run the 
> command and capture
> the output, it takes forever!  It actually starts out at 10,000
> lines/minute, which I can live with I suppose (2.5 hours 
> total), but then
> it slows down progressively until it's crawling at  700 
> lines/minute.  At
> this rate, it will take 32 hours to finish.
> 
> Why does capturing output with Expect, slow things down so 
> dramatically?
> I've tried tweaking my Expect loop, removing regex matching 
> (that helped),
> but most of the things I've tried - removing all patterns, setting
> restart_timeout_upon_receive=1, increasing match_max - don't make a
> difference.
> 
> What is the best way to debug this?  Due to the amount of data, it's
> impractical to turn on normal debugging (Debug, Exp_Internal, 
> Log_Stdout).
> I'm tracking the progress by setting log_file.  I don't know 
> how much this
> slows things down.  Possibly a lot, but when I didn't do 
> that, the program
> would die with no indication why.
> 
> Any guidance would be greatly appreciated.
> 
> Rick Jasper
> 
> 
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

[Expectperl-discuss] Beginner Questions: Reference & How to Handle Large Output

[Rick_Jasper/Delphion%<DEL...@de...>]

Where's the best how-to/tutorial reference for Expect under Perl for
beginners?  I have the Exploring Expect and Perl books, but the Expect book
is difficult to digest and the Perl books don't have much on Expect.  I'm
looking for good, detailed examples of using the Perl/Expect module, not
the Tcl/Expect, aimed at the novice.  The pod is sparse and presumes more
Perl and Expect experience than I have.

I've got Expect 1.12 on an AIX 4.3.3 system, trying to figure out how best
to use it to ssh to some other system overseas, run a command on that
oversea system that produces a lot of output (1.5 million lines, 136 MB
total), collect and process that output on my system.

When I ssh to the remote system and run the command manually, the 1.5
million lines scrolls past my screen in 46 minutes (that's 32,000
lines/minute).  But when I use Expect to login, run the command and capture
the output, it takes forever!  It actually starts out at 10,000
lines/minute, which I can live with I suppose (2.5 hours total), but then
it slows down progressively until it's crawling at  700 lines/minute.  At
this rate, it will take 32 hours to finish.

Why does capturing output with Expect, slow things down so dramatically?
I've tried tweaking my Expect loop, removing regex matching (that helped),
but most of the things I've tried - removing all patterns, setting
restart_timeout_upon_receive=1, increasing match_max - don't make a
difference.

What is the best way to debug this?  Due to the amount of data, it's
impractical to turn on normal debugging (Debug, Exp_Internal, Log_Stdout).
I'm tracking the progress by setting log_file.  I don't know how much this
slows things down.  Possibly a lot, but when I didn't do that, the program
would die with no indication why.

Any guidance would be greatly appreciated.

Rick Jasper

Re: [Expectperl-discuss] IO-Tty vs. BSD

[<RGi...@a1...>]

> I am unable to get IO-Tty to work on BSD (FreeBSD 4.2 and OpenBSD 
> 2.8).

The problem is multi-layered:  0.92_04 is a BETA version, 
the latest stable version is 0.05.  Unfortunately, search.cpan.org
only shows the latest version, regardless of it's status (the
"_" in the version number makes it beta; this is a CPAN
standard).  If you use the (latest) CPAN module, you should
get v0.05, unless there is still a mix-up in the CPAN database
(as it was a few months ago).

I have already contacted the search.cpan.org maintainers to get
that "feature" sorted out.

I'm still working on the innards of IO::Tty to finally get a clean
and cross-platform design, but that's not easy, as there are
about a dozen different ways how ptys are created on various systems,
so this will take a while.

Hope this helps,

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

Re: [Expectperl-discuss] IO-Tty vs. BSD

[Greg M. <la...@ms...>]

On Mon, 07 Jan 2002, Joe Eggleston wrote:

> I am unable to get IO-Tty to work on BSD (FreeBSD 4.2 and OpenBSD 2.8).

I have IO-Tty-0.04 installed without root privileges on FreeBSD,
but I can't find where it all took place now. Did I do it with CPAN or
not?

-- 
Greg Matheson                    The best jokes are 
Chinmin College                  those you play on
                                 yourself.
Taiwan Penpals Archive <URL: http://netcity.hinet.net/kurage>

[Expectperl-discuss] IO-Tty vs. BSD

[Joe E. <jo...@ar...>]

I am unable to get IO-Tty to work on BSD (FreeBSD 4.2 and OpenBSD 2.8).
make test gives the following error:
# make test
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib
-I/usr/libdata/perl/5.00503/mach -I/usr/libdata/perl/5.00503 test.pl
Using /root/IO-Tty-0.92_04/blib
1..12
Configuration: -DHAVE_LIBUTIL_H -DHAVE_OPENPTY -DHAVE_SIGACTION
-DHAVE_STRLCPY -DHAVE_TTYNAME
Checking for appropriate ioctls: TIOCNOTTY TIOCSCTTY
Cannot open slave /dev/ptyp3: Input/output error at test.pl line 47
Sync returned EOF at /root/IO-Tty-0.92_04/blib/lib/IO/Pty.pm line 108.
*** Error code 141

Stop in /root/IO-Tty-0.92_04.

Any ideas?
thanks,
-Joe

Re: [Expectperl-discuss] timeout handler parameters

[Roland G. <RGi...@CP...>]

>   I'm not exactly sure what parameters a timeout handler gets.  I originally
> expected it to get the Expect object as its first parameter, like the other
> handlers in an expect().

That's a little bit of a problem if you have multiple expect objects (using '-i').
Which one should it get?  Should multiple timeout handles be allowed, one for
each '-i'?  I was in a hurry and decided to make timeout handlers global
to all expect objects in that expect() call.

>   A useful workaround is to use a closure for the handler:
> 
> my $exp = Expect->spawn(...);
> $exp->expect(10,
>              [qr/this.*/ => sub { $exp->send($response) } ],
>              [timeout => sub { $exp->send($workaround) } ]);
> 
>   In this way, it's not necessary to access the parameter list in the
> handlers.

Right.  And it also works for multiple expect objects.  I will put that into
the docs...

>   Internally, I'm thinking _multi_expect() could use some reorganization to
> call all the handlers in the same way.  Then, timeout handlers could use
> exp_continue, receive the Expect object as a parameter, etc.

You're right, the whole code could use a lot of cleanup.  But as Expect2
is becoming a possibility, anything invested here is wasted.

>   Hope I don't sound like I'm complaining; Expect.pm still rocks my world!

Not at all!  Constructive criticism is always welcome.

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

[Expectperl-discuss] timeout handler parameters

[Blackstone, J. D. <jda...@ci...>]

  I'm not exactly sure what parameters a timeout handler gets.  I originally
expected it to get the Expect object as its first parameter, like the other
handlers in an expect().

  A useful workaround is to use a closure for the handler:

my $exp = Expect->spawn(...);
$exp->expect(10,
             [qr/this.*/ => sub { $exp->send($response) } ],
             [timeout => sub { $exp->send($workaround) } ]);

  In this way, it's not necessary to access the parameter list in the
handlers.


  Internally, I'm thinking _multi_expect() could use some reorganization to
call all the handlers in the same way.  Then, timeout handlers could use
exp_continue, receive the Expect object as a parameter, etc.


  Hope I don't sound like I'm complaining; Expect.pm still rocks my world!

jdb

Re: [Expectperl-discuss] Install-test problem

[Roland G. <RGi...@a1...>]

> I think warnings only need to be printed once.... or twice

Right, that's already fixed in 1.13_02.

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

Re: [Expectperl-discuss] Install-test problem

[Kevin S. <ke...@ne...>]

I just installed Expect v1.13_1

ran make test

I think warnings only need to be printed once.... or twice

bash-2.05# make
cp Expect.pod blib/lib/Expect.pod
cp Expect.pm blib/lib/Expect.pm
Manifying blib/man3/Expect.3
bash-2.05# make test
PERL_DL_NONLAZY=1
/usr/local/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/perl5/5.6.1/sun4
-solaris -I/usr/local/lib/perl5/5.6.1 test.pl
1..16
ok 1
ok 2
ok 3
ok 4
ok 5
Cannot exec(Ignore_This_Error_Its_A_Test__efluna3w6868tn8): No such file or
directory
ok 6
ok 7
not ok 8
# Failed test 8 in test.pl at line 32
not ok 9
# Failed test 9 in test.pl at line 35
isatty($exp): NO
isatty($exp->slave_pty): YES
The quick brown fox jumped over the lazy dog.
.god yzal eht revo depmuj xof nworb kciuq ehT
ok 10
Ein Neger mit Gazelle zagt im Regen nie
ein negeR mi tgaz ellezaG tim regeN niE
ok 11
Was ich brauche ist ein Lagertonnennotregal
lagertonnennotregaL nie tsi ehcuarb hci saW
ok 12
ok 13
Good, your raw pty can handle at least 512 bytes at a time.
ok 14
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!

Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
Warning: your default pty can only handle 256 bytes at a time!
^Cbash-2.05# make install
Installing /usr/local/lib/perl5/site_perl/5.6.1/Expect.pod
Installing /usr/local/lib/perl5/site_perl/5.6.1/Expect.pm
Installing /usr/local/man/man3/Expect.3
Writing
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Expect/.packlist
Appending installation info to
/usr/local/lib/perl5/5.6.1/sun4-solaris/perllocal.pod



----- Original Message -----
From: "Roland Giersig" <RGi...@a1...>
To: "David G. Schlecht" <ds...@po...>
Cc: <exp...@li...>
Sent: Thursday, December 13, 2001 5:26 AM
Subject: Re: [Expectperl-discuss] Install-test problem


> > I'm installing the latest Expect module on my SunOs v8
> > server. The test fails at test #10. There is no indication
> > as to the cause of the error and looking at the test
> > code doesn't help. CPAN.pm says both Tty and
> > Stty are up to date.
> >
> > Any suggestions?
>
> This is due to a "feature" in the solaris ptys, namely that they cannot
> handle more than a certain number of bytes (several hundreds) in one
> write.  Other systems also have this issue.  On some systems this can
> be worked around by setting the pty to "raw".  Normally you don't have
> to worry about this, Expect should just work fine even with the test
> failing.  I already have enhanced the test in the latest beta version.
>
> Just go ahead and use it.
>
> Hope this helps,
>
> Roland
> --
> RGi...@cp...
>
>
>
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss

RE: [Expectperl-discuss] Patch: exp_continue from timeout handler

[Blackstone, J. D. <jda...@ci...>]

> I'll put it in with the next release, but that can take a while as 
> there are still unresolved issues with the new IO-Tty version I'm 
> working on.

  Thanks!  No hurry.

> PS:  You don't have a test for that patch by chance?

  I started to write one before I wrote the patch, actually, but I made too
much trouble for myself, in the end, and gave up.  I need to look at the
current test suite to see how it works.

jdb

Re: [Expectperl-discuss] Patch: exp_continue from timeout handler

[Roland G. <RGi...@a1...>]

>  Hmm, you can't exp_continue from a timeout handler.  Here's a 
> (reallycrummy) patch to allow it.  A better way would probably be 
> to move the timeout handler stuff into READLOOP somehow...

Thanks a lot, the patch seems to blend in quite well with the rest of 
the crummy code... :-)

I'll put it in with the next release, but that can take a while as 
there are still unresolved issues with the new IO-Tty version I'm 
working on.  It's not easy to be portable across a dozen systems...

Thanks!

Roland
PS:  You don't have a test for that patch by chance?
--
RGi...@cp...

Re: [Expectperl-discuss] Install-test problem

[Roland G. <RGi...@a1...>]

> I'm installing the latest Expect module on my SunOs v8
> server. The test fails at test #10. There is no indication
> as to the cause of the error and looking at the test
> code doesn't help. CPAN.pm says both Tty and
> Stty are up to date.
> 
> Any suggestions?

This is due to a "feature" in the solaris ptys, namely that they cannot 
handle more than a certain number of bytes (several hundreds) in one 
write.  Other systems also have this issue.  On some systems this can 
be worked around by setting the pty to "raw".  Normally you don't have 
to worry about this, Expect should just work fine even with the test 
failing.  I already have enhanced the test in the latest beta version.

Just go ahead and use it.

Hope this helps,

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

[Expectperl-discuss] Install-test problem

[David G. S. <ds...@po...>]

Hi All,

I'm installing the latest Expect module on my SunOs v8
server. The test fails at test #10. There is no indication
as to the cause of the error and looking at the test
code doesn't help. CPAN.pm says both Tty and
Stty are up to date.

Any suggestions?

I use the CPAN module to install and get the following
report:

1..11
ok 1
ok 2
ok 3
ok 4
Cannot exec `efjlewhrerzuna3wc6tb83g6868tn8': No such file or directory
ok 5
ok 6
The quick brown fox jumped over the lazy dog.
The quick brown fox jumped over the lazy dog.
.god yzal eht revo depmuj xof nworb kciuq ehT
ok 7
Ein Neger mit Gazelle zagt im Regen nie
Ein Neger mit Gazelle zagt im Regen nie
ein negeR mi tgaz ellezaG tim regeN niE
ok 8
Was ich brauche ist ein Lagertonnennotregal
Was ich brauche ist ein Lagertonnennotregal
lagertonnennotregaL nie tsi ehcuarb hci saW
ok 9
 fakjdf ijj845jtirg8e 4jy8 gfuoyhjgt8h gues9845th guoaeh gt98hae 45t8u ha8rhg ue

4ht 8eh tgo8he4 t8 gfj aoingf9a8hgf uain dgkjadshftuehgfusand987vgh afugh 8h 98H

 978H 7HG zG 86G (&g (O/g &(GF(/EG F78G F87SG F(/G F(/a sldjkf hajksdhf jkahsd f

jkh asdljkhf lakjsdh fkjahs djfk hasjkdh fjklahs dfkjhasdjkf hajksdh fkjah sdjfk

 hasjkdh fkjashd fjkha sdjkfhehurthuerhtuwe htui eruth
 fakjdf ijj845jtirg8e 4jy8 gfuoyhjgt8h gues9845th guoaeh gt98hae 45t8u ha8rhg ue

4ht 8eh tgo8he4 t8 gfj aoingf9a8hgf uain dgkjadshftuehgfusand987vgh afugh 8h 98H

 978H 7HG zG 86G (&g (O/g &(GF(/EG F78G F87SG F(/G F(/a sldjkf hajksdhf jkahsd f

jkh asdljkhf lakjnot ok 10
# Failed test 10 in test.pl at line 51
Timeout at test.pl line 51.
make: *** [test_dynamic] Error 1
  /usr/local/bin/make test -- NOT OK
Running make install
  make test had returned bad status, won't install without force


Thank you.

-Dave

[Expectperl-discuss] Patch: exp_continue from timeout handler

[Blackstone, J. D. <jda...@ci...>]

  Hmm, you can't exp_continue from a timeout handler.  Here's a (really
crummy) patch to allow it.  A better way would probably be to move the
timeout handler stuff into READLOOP somehow...

jdb

--- /usr/local/perl561/lib/site_perl/5.6.1/Expect.pm    Wed Aug 22 06:08:15
2001
+++ Expect.pm   Tue Dec 11 09:46:08 2001
@@ -539,10 +539,12 @@
   my $match;
   my @matchlist;

+TIMEOUT_CONT_LOOP:
+while (1) {
   # Set the last loop time to now for time comparisons at end of loop.
   my $start_loop_time = time();
   my $exp_cont = 1;
-
+  $err = "";
  READLOOP:
   while ($exp_cont) {
     $exp_cont = 1;
@@ -805,18 +807,27 @@
     if ($timeout_hook) {
       print STDERR ("Calling timeout function $timeout_hook...\r\n")
        if ($Expect::Debug or $Expect::Exp_Internal);
+      my $timeout_cont = 0;
       if (ref($timeout_hook) eq 'CODE') {
-       &{$timeout_hook}($_[0]->[0]);
+       $timeout_cont = &{$timeout_hook}($_[0]->[0]);
       } else {
        if ($#{$timeout_hook} > 3) {
-         &{$timeout_hook->[3]}($_[0]->[0],
+         $timeout_cont = &{$timeout_hook->[3]}($_[0]->[0],
                                @{$timeout_hook}[4..$#{$timeout_hook}]);
        } else {
-         &{$timeout_hook->[3]}($_[0]->[0]);
+         $timeout_cont = &{$timeout_hook->[3]}($_[0]->[0]);
        }
       }
+      if ($timeout_cont and ($timeout_cont eq "exp_continue"))
+      {
+        print STDERR ("Continuing expect, restarting timeout...\r\n")
+          if ($Expect::Debug);
+        next TIMEOUT_CONT_LOOP;
+      }
     }
   }
+last TIMEOUT_CONT_LOOP;
+}

   # Tell us status
   if ($Expect::Debug or $Expect::Exp_Internal) {

Re: [Expectperl-discuss] -notransfer ?

[Roland G. <RGi...@CP...>]

>   The idea is I could make my code cleaner and more modular if I could end
> some routines by expecting a string to make sure of my location in the menu
> system, but still leave the string in the buffer.  I can live without it,
> but it's a very attractive thought.

Hmm, sounds sound.  Unfortunately it has to wait until I finish the
IO-Tty release, which may still take a while.  I'll put it on the to-do-list.

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

Re: [Expectperl-discuss] Has anyone re-written original dislocate in Expect.pm?

[Roland G. <RGi...@CP...>]

> The 'dislocate' allows a user to run a UNIX application from a terminal
> window, abandon it but let the process continue, and then connect back
> into the process as if you had never left it.  The good thing about the
> script is that you can logoff the machine from work and login at home
> and continue to monitor your process.

Ah, I remember!  That has been covered in detail in the Expect book.  
No, I don't know if anybody is working on that, but it seems like a splendid
idea to have such a tool around.  You might want to take a look at IPC::Run
(which BTW also makes use of IO::Pty), which overlaps with Expects 
interconnect() functionality and might be more suitable for such a tool. 
 
I don't want to discourage the use of Expect, but I see Perl/Expect with 
a more limited functionality, more in the Unix tradition of one fundamental 
functionality per module, not the do-it-all-and-more approach of Tcl/Expect.

Just my EUR 0.02

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

Re: [Expectperl-discuss] Has anyone re-written original dislocate in Expect.pm?

[John C. P. <jcp...@au...>]

Roland,

The 'dislocate' allows a user to run a UNIX application from a terminal 
window, abandon it but let the process continue, and then connect back 
into the process as if you had never left it.  The good thing about the 
script is that you can logoff the machine from work and login at home 
and continue to monitor your process.

I have tried VNCviewer, but it doesn't work on some systems.

Cheers,
John

On Friday, December 7, 2001, at 02:49  AM, Roland Giersig wrote:

>> Has anyone re-written original dislocate script?
>
> Excuse me, my Tcl/Expect experience is a little bit rusted, what
> is 'dislocate' doing?  Something like 'nohup'?
>
> Roland
> --
> RGi...@cp...
>
>
>
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>

RE: [Expectperl-discuss] 2.4.14 Linux Kernel

[Blackstone, J. D. <jda...@ci...>]

  I'm guessing your problem is the job control thing.

  Actually, I'm main writing this to say, "Thank you for pointing out the
clear_accum method!  I hadn't noticed it and needed it!"

> Note that "program" mush be run from a shell. Don't ask.

:)


  Have you considered backgrounding your Expect.pm Perl program instead of
backgrounding the process you're trying to run with it?  Actually, since
you're already doing the daemon thing, you might reevaluate whether you need
to do the background at all ...

----- Oh!!!!! ------

  Proc::Daemon::Init is your problem.  It's also your solution.  (Using it,
you've already backgrounded your daemon, so you don't really need to
background the ./program .  If you need to keep running something else at
the same time, consider forking.)

  By becoming a proper daemon, you've set up a process that's the head of
its own process group.  (Or not a member of a process group, or something
like that.)  Process groups are what are used for job control.  So, you
can't possibly do ./program & .  However, like I said, I don't think you
actually need to.

jdb

> -----Original Message-----
> From: ksc...@mi... [mailto:ksc...@mi...]
> Sent: Friday, December 07, 2001 11:49 AM
> To: exp...@li...
> Subject: RE: [Expectperl-discuss] 2.4.14 Linux Kernel
> 
> 
> In short, here is what I'm doing:
> 
> Proc::Daemon::Init unless $no_daemon;
> my $exp = Expect->spawn("/bin/bash");
> my $prompt = '#|\$';
> $exp->exp_internal(1);
> $exp->expect(5,-re=>$prompt);
> $exp->clear_accum();
> $exp->send("cd /home/kjs/application\n");
> $exp->clear_accum();
> $exp->expect(5,-re=>$prompt);
> $exp->clear_accum();
> $exp->send("nohup ./program -daemon &\n");
> 
> Note that "program" mush be run from a shell. Don't ask. Anyway, on
> the older linux system, this work. When I run it on the newer kernel,
> the last Expect send statement doesn't seem to get executed until I
> either ctrl-c my Expect script or I kill -9 it. Then "program" shows
> up in a ps listing. Here's what I get when I run it on the new system:
> 
> Here's the output of the Expect script on the newer Linux kernel:
> 
> 
> 
> Starting EXPECT pattern matching...
> 	Expect::expect('Expect=GLOB(0x8421148)', 5, '-re', 
> '#|\$') called at
> ns_control.pl line 58
> spawn id(4): list of patterns:
>   #1: -re `#|\\$'
> 
> bash: no job control in this shell
> 
> spawn id(4): Does `bash: no job control in this shell\r\n'
> match:
>   pattern #1: -re `#|\\$'? No.
> 
> bash-2.04$ 
> spawn id(4): Does `bash: no job control in this shell\r\nbash-2.04$ '
> match:
>   pattern #1: -re `#|\\$'? YES!!
>     Before match string: `bash: no job control in this 
> shell\r\nbash-2.04'
>     Match string: `$'
>     After match string: ` '
>     Matchlist: ()
> Sending 'cd /home/kjs/application\n' to spawn id(4)
> 	Expect::print('Expect=GLOB(0x8421148)', 'cd 
> /home/kjs/applicaiton^J')
> called at ns_control.pl line 60
> Starting EXPECT pattern matching...
> 	Expect::expect('Expect=GLOB(0x8421148)', 5, '-re', 
> '#|\$') called at
> ns_control.pl line 63
> spawn id(4): list of patterns:
>   #1: -re `#|\\$'
> 
> 
> spawn id(4): Does `'
> match:
>   pattern #1: -re `#|\\$'? No.
> 
> cd /home/kjs/application
> 
> spawn id(4): Does `cd /home/kjs/application\r\n'
> match:
>   pattern #1: -re `#|\\$'? No.
> 
> bash-2.04$ 
> spawn id(4): Does `cd /home/kjs/application\r\nbash-2.04$ '
> match:
>   pattern #1: -re `#|\\$'? YES!!
>     Before match string: `cd /home/kjs/application\r\nbash-2.04'
>     Match string: `$'
>     After match string: ` '
>     Matchlist: ()
> Sending 'nohup ./program -daemon &\n' to spawn id(4)
> 	Expect::print('Expect=GLOB(0x8421148)', 'nohup 
> ./program -daemon &^J')
> called at ns_control.pl line 72
> 
> 
> Notice the "bash: no job control in this shell" at the top of the
> Expect output. This the only difference between the output on the new
> kernel and the old kernel. This is probably the problem. Any idea how
> I can fix it?
> 
> Thanks,
> -Kevin
> 
> 
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

Fwd: RE: [Expectperl-discuss] 2.4.14 Linux Kernel

[<ksc...@mi...>]

I should also mention that I'm using perl2exe (www.indigostar.com) to
compile this script into a binary executable. I compile it on the
system where Expect.pm and IO-Tty are installed, then copy the binary
over to another machine, i.e. the machine with the newer kernel. I
don't know if this could be part or the problem or not, so I figured I
would at least mention it.

Thanks,
-Kevin


ksc...@mi... wrote:
> In short, here is what I'm doing:

Proc::Daemon::Init unless $no_daemon;
my $exp = Expect->spawn("/bin/bash");
my $prompt = '#|\$';
$exp->exp_internal(1);
$exp->expect(5,-re=>$prompt);
$exp->clear_accum();
$exp->send("cd /home/kjs/application\n");
$exp->clear_accum();
$exp->expect(5,-re=>$prompt);
$exp->clear_accum();
$exp->send("nohup ./program -daemon &\n");

Note that "program" mush be run from a shell. Don't ask. Anyway, on
the older linux system, this work. When I run it on the newer kernel,
the last Expect send statement doesn't seem to get executed until I
either ctrl-c my Expect script or I kill -9 it. Then "program" shows
up in a ps listing. Here's what I get when I run it on the new system:

Here's the output of the Expect script on the newer Linux kernel:



Starting EXPECT pattern matching...
	Expect::expect('Expect=GLOB(0x8421148)', 5, '-re', '#|\$') called at
ns_control.pl line 58
spawn id(4): list of patterns:
  #1: -re `#|\\$'

bash: no job control in this shell

spawn id(4): Does `bash: no job control in this shell\r\n'
match:
  pattern #1: -re `#|\\$'? No.

bash-2.04$ 
spawn id(4): Does `bash: no job control in this shell\r\nbash-2.04$ '
match:
  pattern #1: -re `#|\\$'? YES!!
    Before match string: `bash: no job control in this shell\r\nbash-2.04'
    Match string: `$'
    After match string: ` '
    Matchlist: ()
Sending 'cd /home/kjs/application\n' to spawn id(4)
	Expect::print('Expect=GLOB(0x8421148)', 'cd /home/kjs/applicaiton^J')
called at ns_control.pl line 60
Starting EXPECT pattern matching...
	Expect::expect('Expect=GLOB(0x8421148)', 5, '-re', '#|\$') called at
ns_control.pl line 63
spawn id(4): list of patterns:
  #1: -re `#|\\$'


spawn id(4): Does `'
match:
  pattern #1: -re `#|\\$'? No.

cd /home/kjs/application

spawn id(4): Does `cd /home/kjs/application\r\n'
match:
  pattern #1: -re `#|\\$'? No.

bash-2.04$ 
spawn id(4): Does `cd /home/kjs/application\r\nbash-2.04$ '
match:
  pattern #1: -re `#|\\$'? YES!!
    Before match string: `cd /home/kjs/application\r\nbash-2.04'
    Match string: `$'
    After match string: ` '
    Matchlist: ()
Sending 'nohup ./program -daemon &\n' to spawn id(4)
	Expect::print('Expect=GLOB(0x8421148)', 'nohup ./program -daemon &^J')
called at ns_control.pl line 72


Notice the "bash: no job control in this shell" at the top of the
Expect output. This the only difference between the output on the new
kernel and the old kernel. This is probably the problem. Any idea how
I can fix it?

Thanks,
-Kevin


_______________________________________________
Expectperl-discuss mailing list
Exp...@li...
https://lists.sourceforge.net/lists/listinfo/expectperl-discuss