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

Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

[Austin S. <te...@of...>]

On Mon, Mar 18, 2002 at 04:42:58PM +0100, RGi...@a1... wrote:
> > > definitely a waste of time
> > 
> > 	My point is that if a programmer knows that the wheel already
> > exists, calling what they do a waste of time is an unnecessary 
> > judgement.Why not assume they are competent to decide for themselves?
> 
> Sorry if I stepped on your toes.  I concurr that competent programmers 
> should decide for themselves how they solve their problems, but given 
> the kind of requests that I increasingly keep getting, that species is 
> getting severely pushed back... :-)
> 

	My toes are fine. :-)
	Perhaps if we're getting a lot of these sorts of questions we should
add answers in the FAQ, e.g. pointers to Net::Ftp docs and ncftp. Seems
like we might want to revisit the FAQ anyway - looks like some of the earlier
problems esp. in regards to poorly behaved ttys have since been fixed.

> Have a beer on me.  Cheers!
> 

	When the economy improves a little we should have an Expectperl
gathering at a perl conference. Then I'll take you up on the offer. :-)

	Austin

RE: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

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

Hi, folks,

  This isn't a legislative body.  We're not going to decide the one best way
and force it on everyone. :)

  That said, all of our experiences give us different insights and in the
Perl community noone holds back on sharing their insights.  (And very few
hold back on insisting that their insight is the best.)  So, at any rate,
I'll tell you what I know, and what I think, and you can take it or leave
it. :)

  Happy coding!

jdb

> -----Original Message-----
> From: RGi...@a1... [mailto:RGi...@a1...]
> Sent: Monday, March 18, 2002 9:43 AM
> To: Austin Schutz
> Cc: 'Expectperl-Discuss (E-mail)'
> Subject: Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and
> Linux
> 
> 
> > > Nothing against TMTOWTDI, but keeping re-inventing the wheel is 
> > > definitely a waste of time
> > 
> > 	My point is that if a programmer knows that the wheel already
> > exists, calling what they do a waste of time is an unnecessary 
> > judgement.Why not assume they are competent to decide for 
> themselves?
> 
> Sorry if I stepped on your toes.  I concurr that competent 
> programmers 
> should decide for themselves how they solve their problems, but given 
> the kind of requests that I increasingly keep getting, that 
> species is 
> getting severely pushed back... :-)

Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

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

> > Nothing against TMTOWTDI, but keeping re-inventing the wheel is 
> > definitely a waste of time
> 
> 	My point is that if a programmer knows that the wheel already
> exists, calling what they do a waste of time is an unnecessary 
> judgement.Why not assume they are competent to decide for themselves?

Sorry if I stepped on your toes.  I concurr that competent programmers 
should decide for themselves how they solve their problems, but given 
the kind of requests that I increasingly keep getting, that species is 
getting severely pushed back... :-)

> 	Please walk a mile in my shoes before calling what I
> do{} while me() a waste of time. 

I again appologize, this wasn't directed at you but at the hordes of 
newbies that have no programming experience, don't know perl and want 
to use Expect to automate ftp.  Moreover, they want somebody else to 
solve their problems for them.  The Mircosoft Generation...

Have a beer on me.  Cheers!

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

Re: [Expectperl-discuss] several sequental spawns

[Austin S. <te...@of...>]

> I got a message here in logs telling that /dev/pts/7 which was used for
> the first program interaction doesn't exist anymore (no such file or
> directory)
> 
> If I replace the second $expect->spawn with Expect->spawn the program
> works Ok. Is there a way to skip creation of another Expect object, or
> at least cloning settings from the first object to the second one?
> 

	You would be able to do something like:

$new_expect = Expect->new();
%{ *$new_expect } = %{ *$old_expect };

	except there are are a few variables you don't want to change, such
as the name of the pty, etc.
	If there are a few settings in particular you are interested in
setting it would probably be easiest to copy them before you destroy
to old object, e.g.:


sub copy_settings {
  my($old,$new) = @_;
  $new->exp_internal($old->exp_internal());
  ...
}

$new = Expect->new();
copy_settings($old,$new);
undef($old);

	As Roland says, we might want to make this a new sub in the Expect
module. I'm not sure which items we'd want to have in there by default,
e.g. terminal params(?).

	Austin

Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

[Austin S. <te...@of...>]

On Mon, Mar 18, 2002 at 09:31:50AM +0100, RGi...@a1... wrote:
> Nothing against TMTOWTDI, but keeping re-inventing the wheel is 
> definitely a waste of time

	My point is that if a programmer knows that the wheel already
exists, calling what they do a waste of time is an unnecessary judgement.
Why not assume they are competent to decide for themselves?

>, given that there are stable, versatile, 
> well-tested tools out there that already do what you want.  Instead of 
> automating the ftp client for the 1000th time and falling into the trap 
> of not thinking about error cases, take a look at ncftp 
> (http://www.ncftp.org), which is scriptable and thus very useful in 
> solving all kinds of sysadmin problems involving file transfer.
> 

	Which I would probably consider a waste of time vs. using Net::Ftp.
My point is that you should be given the benefit of the doubt that what you
code for yourself is the best use of your own resources, which may include
your time, your boss's money, security concerns, etc.
	Please walk a mile in my shoes before calling what I do{} while me()
a waste of time. 

	Austin

Re: [Expectperl-discuss] several sequental spawns

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

> It looks like perl-Expect doesn't support for several subsequent 
> spawns for on objects

Right, I never checked if this works, so it doesn't. :-)
 
> I got a message here in logs telling that /dev/pts/7 which was 
> used for the first program interaction doesn't exist anymore
> (no such file or directory)

This probably comes from the pty that is closed but not completely 
destroyed.

> If I replace the second $expect->spawn with Expect->spawn the program
> works Ok.

Because then you are creating a new object.

> Is there a way to skip creation of another Expect object, or
> at least cloning settings from the first object to the second one?

Sorry, no, not at the moment.  I'll add this to the 'to do' list...

Thanks for the suggestion!

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

Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

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

> > You should at least read the documentation for Net::FTP before 
> you decide.
> > It's extremely easy to use.
> > You probably could have re-written your app in 1/100th of the 
> time we've all spent 
> > on this email thread today.
> > 
> 
> 	I'm sure that's true, and yet I'll waste it with one more 
reiteration
> of 'TMTOWTDI'. I find in the perl community that despite TMTOWTDI 
> being a catch phrase, there is frequently discussion about how one 
> method is always better in all situations.

Nothing against TMTOWTDI, but keeping re-inventing the wheel is 
definitely a waste of time, given that there are stable, versatile, 
well-tested tools out there that already do what you want.  Instead of 
automating the ftp client for the 1000th time and falling into the trap 
of not thinking about error cases, take a look at ncftp 
(http://www.ncftp.org), which is scriptable and thus very useful in 
solving all kinds of sysadmin problems involving file transfer.

TMTOWTDI should always be used on problem level before trying to use it 
on implementation level...

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

Re: [Expectperl-discuss] No match,

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

> I don't like deleting the anchoring to the beginning of the line, 
> since it might get an accidental match with comments or other 
arbitrary
> strings in the router's config.

Then how about anchoring it to the end of buffer ("\Z")?  The prompt 
should be the *last* output, right?

> > Have you set $exp->match_max?
> 
> My script by default sets it to 256k, and the user can specify it
> on the command line.  And if I was overrunning the accumulator,
> wouldn't I just lose the beginning of the data I want rather than
> not match the end?

Right, this was just a hunch.

> Hopefully a few more people will start using the script and I'll
> get some more feedback.  Very strange...

I had another report that the new Expect version suddenly doesn't match 
something that an old version matched.  I'm waiting for additional data 
and will keep you (well, the mailing list) posted.

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

Re: [Expectperl-discuss] IO-TTy installation error on AIX

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

> I had a similiar problem installing IO-Tty-1.0, but with "cpp".  On
> my Red Hat 6.2 box, I was told that it couldn't find "cpp".  Well,
> sure enough, "cpp" was in some exotic place so I added it to my
> PATH and tried again.  This time, I got the complaint that "cpp" 
> didn't like one of the options in its flags.  I modified Config.pm 
> to yank that offending option, and then the install went OK. 
> That was with Perl 5.6.1 - perhaps there are issues with the
> production of Config.pm?

Yes, that's a common problem, as I had to find out the past few days.  
The details are:  on RH6.2, perl is configured with gcc and due to some 
glitch, a compiler option is added to the cppflags, which is ignored by 
gcc's version of cpp, but unfortunately not by other cpps.  As I have 
learned, $Config{cpp} isn't really set to something useful after perl 
is configured, instead, $Config{cpprun} should be used.  Don't ask me 
why...

Anyway, I'll continue to fiddle around to get it portably running, in 
the meantime just remove the offending option...

HTH,

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

[Expectperl-discuss] several sequental spawns

[Alexey M. <mo...@no...>]

It looks like perl-Expect doesn't support for several subsequent spawns
for on objects, smth like this

my $expect = Expect->new(...);
# setting some parameters for the object created
#...
$expect->spawn('first_program',@parameters);
$expect->expect(smth);
$expect->soft_close or $expect->hard_close;
print $expect->existatus;
...

$expect->spawn('another_program',@parameters);

I got a message here in logs telling that /dev/pts/7 which was used for
the first program interaction doesn't exist anymore (no such file or
directory)

If I replace the second $expect->spawn with Expect->spawn the program
works Ok. Is there a way to skip creation of another Expect object, or
at least cloning settings from the first object to the second one?

Alexey Morozov

Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

[Austin S. <te...@of...>]

On Fri, Mar 15, 2002 at 03:14:33PM -0500, Martin 'Kingpin' Thurn wrote:
> > I disagree with using Net::* for everything, in all cases. I 
> 
> You should at least read the documentation for Net::FTP before you decide.
> It's extremely easy to use.
> You probably could have re-written your app in 1/100th of the time we've all spent 
> on this email thread today.
> 

	I'm sure that's true, and yet I'll waste it with one more reiteration
of 'TMTOWTDI'. I find in the perl community that despite TMTOWTDI being
a catch phrase, there is frequently discussion about how one method is always
better in all situations.

	Austin

RE: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

[Martin 'K. T. <mt...@ta...>]

> I disagree with using Net::* for everything, in all cases. I 

You should at least read the documentation for Net::FTP before you decide.
It's extremely easy to use.
You probably could have re-written your app in 1/100th of the time we've all spent 
on this email thread today.

--
 - - Kingpin

[interesting witty quote unavailable, thanks to lack of features in MS Outlook]

Re: [Expectperl-discuss] No match,

[Ed R. <er...@pa...>]

RGi...@a1... writes:
> 
> > > >   pattern #1: -re `^cs3mc-lab-e0a(\\(\S+\))?#'? No.
> > >                                     ^^    ^
> > > 	Hmm, this is interesting. Two backslashes in one spot, one
> > > in the next.
> 
> Looks like a glitch in Perl to me.  And the "\012" is also fishy.
> What system is the user running on?

Red Hat 7.2, Perl 5.6.0.  And I saw the same thing with Red Hat 6.2,
Perl 5.6.1.  Haven't tried NetBSD and perl 5.6.x yet.

> I'd try to fiddle with the regexp:  qr"\b$routername(?:\(\S+\))?#" 
> should work as well, or qr"$routername(?:\(\S+\))?#\Z".

Well, that's something like what I suggested to the user, and he says
it's working now - instead of

        $router_prompt= '^' . $routername . '(\(\S+\))?#';

He deleted the '^' and simplifed the right match pattern.  Hopefully
he'll send me the exact code so I'll get a better idea of what works.
I don't like deleting the anchoring to the beginning of the line, since
it might get an accidental match with comments or other arbitrary
strings in the router's config.

> > > >   However, the big difference between the early commands
> > > > that matched and the one that failed is that the latter 
> > produces hundreds
> > > > of lines of output

> Have you set $exp->match_max?

My script by default sets it to 256k, and the user can specify it
on the command line.  And if I was overrunning the accumulator,
wouldn't I just lose the beginning of the data I want rather than
not match the end?

Hopefully a few more people will start using the script and I'll
get some more feedback.  Very strange...

Re: [Expectperl-discuss] IO-TTy installation error on AIX

[Ed R. <er...@pa...>]

> > While trying to install  IO-Tty-0.97_01  I get the following error:
> > 
> > 	/home/root/IO-Tty-0.97_01# perl Makefile.PL
> > 	Now let's see what we can find out about your system
> > 	(logfiles of failing tests are available in the conf/ dir)...
> > 
> > 	ERROR: cannot run the configured compiler cc_r
> > 	(see conf/compilerok.log).  Maybe you should build perl by 
> yourself?
...
> Perl has been configured to use 'cc_r' as its C compiler, but noew it 
> cannot be found in the PATH.

I had a similiar problem installing IO-Tty-1.0, but with "cpp".  On
my Red Hat 6.2 box, I was told that it couldn't find "cpp".  Well,
sure enough, "cpp" was in some exotic place so I added it to my
PATH and tried again.  This time, I got the complaint that "cpp" didn't
like one of the options in its flags.  I modified Config.pm to yank
that offending option, and then the install went OK.  That was with
Perl 5.6.1 - perhaps there are issues with the production of Config.pm?

> If you don't have 'cc_r' installed, 
> either edit Config.pm and change all commands and flags etc. to gcc 
> (ugh!) or build perl yourself using gcc.  Also, ask your friendly 
> sysadmin for help.

Funny.  I'm so used to making minor patches to these things that I
forgot completely about that problem until I read the post above.

Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

[Austin S. <te...@of...>]

On Fri, Mar 15, 2002 at 09:00:17AM -0600, Blackstone, J. David wrote:
>   I would never automate an FTP session by wrapping Expect/Expect.pm around
> an FTP client.  Use Net::FTP.  I know the Expect book talks about automating
> an FTP session, but it's a bad idea when you have a module to do it for you
> (and when you can't depend on your FTP clients to behave the same way on
> different systems).
> 

	While I agree with the idea of using it on a poorly behaved platform,
I disagree with using Net::* for everything, in all cases. I write a lot
of expect code that doesn't need to be ultra-portable and I generally don't
feel like trying to learn/use/debug each and every module's API.
As they say, TMTOWTDI. Different things may be appropriate in different
situations. As long as a programmer is aware of other methods, let them
decide for themselves.

	Austin

RE: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

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

  I would never automate an FTP session by wrapping Expect/Expect.pm around
an FTP client.  Use Net::FTP.  I know the Expect book talks about automating
an FTP session, but it's a bad idea when you have a module to do it for you
(and when you can't depend on your FTP clients to behave the same way on
different systems).

jdb

> -----Original Message-----
> From: RGi...@a1... [mailto:RGi...@a1...]
> Sent: Friday, March 15, 2002 2:59 AM
> To: Chen leonard-a17094
> Cc: Expectperl-Discuss (E-mail)
> Subject: Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and
> Linux
> 
> 
> > When I try to automate 'ftp' under WINNT(CYGWIN_NT-4.0),
> 
> Don't.  Take a look at ncftp (http://www.ncftp.org), which is 
> scriptable and also runs natively under Windows.

Re: [Expectperl-discuss] No match, but the pattern is there in debug output

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

> > >   pattern #1: -re `^cs3mc-lab-e0a(\\(\S+\))?#'? No.
> >                                     ^^    ^
> > 	Hmm, this is interesting. Two backslashes in one spot, one
> > in the next.

Looks like a glitch in Perl to me.  And the "\012" is also fishy.
What system is the user running on?

> It's a regexp to match the Cisco router prompt, which is of the form:
> 
>   "Router#"  or "Router(config-nacl-ext)#" or "Router(otherjunk)#"
> 
> So I want to match "Router(any junk between parens or no parens at 
> all)#".

I'd try to fiddle with the regexp:  qr"\b$routername(?:\(\S+\))?#" 
should work as well, or qr"$routername(?:\(\S+\))?#\Z".

> And it works for me, and since the user says it matches the 
> first three times when he runs the script, I can't see how
> anything could be wrong with it.

Oh, maybe the regexp engine has problems...  maybe not.

> > >   However, the big difference between the early commands
> > > that matched and the one that failed is that the latter 
> produces hundreds
> > > of lines of output, while the successful commands produced 
> either 30-40
> > > lines (the "show term") or none at all (the two "set term" 
> commands) except
> > > for the router's prompt.

Have you set $exp->match_max?  Normally the accum doesn't get 
truncated, maybe the regexp engine has problems when matching large 
amounts of data (though I cannot imagine why this wouldn't be detected 
earlier).

> Could there be a race condition in Expect.pm such that if the data
> arrives just before or after the timeout, it might end up in the
> accumulator (or at least in the debug output of the accumulator)
> after the operation timed out?

Nope, definitely not.  If something is read, it definitely gets checked 
before the timeout can hit.

Hope this helps,

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

Re: [Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

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

> When I try to automate 'ftp' under WINNT(CYGWIN_NT-4.0),

Don't.  Take a look at ncftp (http://www.ncftp.org), which is 
scriptable and also runs natively under Windows.

> I found 
> it acts different from in Linux. Expect is not able to read any 
> thing from 'ftp' in Cygwin. So, why? (the following is the script 
> and logs.)

I have no idea.  Which ftp client does it get?  The Cygwin one or the 
native one?  

Try running 'ftp' with the 'try' script from the IO-Tty dist and see if 
that works.  If that doesn't work then there is something extremely 
fishy...

Hope this helps,

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

Re: [Expectperl-discuss] IO-TTy installation error on AIX

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

> While trying to install  IO-Tty-0.97_01  I get the following error:
> 
> 	/home/root/IO-Tty-0.97_01# perl Makefile.PL
> 	Now let's see what we can find out about your system
> 	(logfiles of failing tests are available in the conf/ dir)...
> 
> 	ERROR: cannot run the configured compiler cc_r
> 	(see conf/compilerok.log).  Maybe you should build perl by 
yourself?
> 
> 	/home/root/IO-Tty-0.97_01# gcc -v
> 	Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-
> aix4.3.2.0/3.0.1/specs	Configured with: ./configure --enable-
> threads=aix --disable-nls
> 	Thread model: single
> 	gcc version 3.0.1

Perl has been configured to use 'cc_r' as its C compiler, but noew it 
cannot be found in the PATH.  If you don't have 'cc_r' installed, 
either edit Config.pm and change all commands and flags etc. to gcc 
(ugh!) or build perl yourself using gcc.  Also, ask your friendly 
sysadmin for help.

Hope this helps,

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

Re: [Expectperl-discuss] No match, but the pattern is there in debug output

[Ed R. <er...@pa...>]

Austin Schutz writes:
> <snip>
> > input none\r\012!\r\012!\r\012end\r\012
> > \r\012cs3mc-lab-e0a#'
> > match:
> >   pattern #1: -re `^cs3mc-lab-e0a(\\(\S+\))?#'? No.
>                                     ^^    ^
> 	Hmm, this is interesting. Two backslashes in one spot, one
> in the next.

Yes, that is odd.  Here's the code that sets that pattern (line 190):

        $router_prompt= '^' . $routername . '(\(\S+\))?#';

And there are no double backslashes.  There's definitely some
kind of artifact here with the way Perl displays stuff, although
I'm not sure whether this is relevant to the problem.  I think
the user must be running Perl 5.6.1 or thereabouts - I just installed
that on my home box and I see both the "\r\012" in the debug display
(instead of "\r\n" as Perl 5.005 does) and the unbalanced backslashes
(instead of `^routername(\\(\\S+\\))?#' which is how Perl 5.005
displays it).

It's a regexp to match the Cisco router prompt, which is of the form:

   "Router#"  or "Router(config-nacl-ext)#" or "Router(otherjunk)#"

So I want to match "Router(any junk between parens or no parens at all)#".
And it works for me, and since the user says it matches the first three
times when he runs the script, I can't see how anything could be wrong
with it.

> >   However, the big difference between the early commands
> > that matched and the one that failed is that the latter produces hundreds
> > of lines of output, while the successful commands produced either 30-40
> > lines (the "show term") or none at all (the two "set term" commands) except
> > for the router's prompt.
> > 
> 	This could be a problem if your timeout isn't set high enough.
> Occasionally slow devices can take a while to respond, particularly if they
> have large numbers of interfaces attached, e.g. heavily loaded  access router.
> Your 10 second timeout default may not be long enough in some cases, though it
> does seem to have gotten the correct data in this case.

Could there be a race condition in Expect.pm such that if the data
arrives just before or after the timeout, it might end up in the
accumulator (or at least in the debug output of the accumulator)
after the operation timed out?

Re: [Expectperl-discuss] No match, but the pattern is there in debug output

[Austin S. <te...@of...>]

<snip>
> input none\r\012!\r\012!\r\012end\r\012
> \r\012cs3mc-lab-e0a#'
> match:
>   pattern #1: -re `^cs3mc-lab-e0a(\\(\S+\))?#'? No.
                                    ^^    ^

	Hmm, this is interesting. Two backslashes in one spot, one
in the next. If you have an escaping problem the regex might fail
with mismatched parens. It's not obvious from the script, but you
might try changing the number of '\'s in the regex.

> 
> Waiting for new data (4 seconds)...
> TIMEOUT
> 
> Well, there's the "\r\012cs3mc-lab-e0a#", the same thing that matched
> previously. When I look at the debug output of the script when I use it,
> it looks the same, except that in my environment the string is printed
> as "\r\ncs3mc-lab-e0a#".
> 
> I don't think the problem is multi-line matching - my program doesn't
> touch $Expect::Multiline_Matching and if I set it to 0 it fails on the
> first match try.  However, the big difference between the early commands
> that matched and the one that failed is that the latter produces hundreds
> of lines of output, while the successful commands produced either 30-40
> lines (the "show term") or none at all (the two "set term" commands) except
> for the router's prompt.
> 
	This could be a problem if your timeout isn't set high enough.
Occasionally slow devices can take a while to respond, particularly if they
have large numbers of interfaces attached, e.g. heavily loaded  access router.
Your 10 second timeout default may not be long enough in some cases, though it
does seem to have gotten the correct data in this case.


	Austin

[Expectperl-discuss] No match, but the pattern is there in debug output

[Ed R. <er...@pa...>]

I'm very confused by this.  I wrote a Perl-expect script that talks
to Cisco routers, and it works great for me under NetBSD 1.5 and Linux
(RH 6.2), Perl 5.005_02 and 5.005_03.  Someone else trying to use it
reported that it would time out halfway, claiming it couldn't see the
router's prompt.  The strange thing is that the script matched the router
prompt three times previously, and when you look at the debug output,
you can see the router's prompt as the last thing in the buffer.

Can anyone make suggestions on how to debug this?  The first thing
I looked at was environment - I forgot to ask the person what version
of Perl he's using, but he's tried Expect 1.11 (the one I developed
the script under) as well as 1.13 and 1.14, and IO::Tty 0.04 and 0.05,
no difference.

Here's my script's basic debug output:

aclmaker.pl: sent CR, received { terminal length 0 ! restore old setting
cs3mc-lab-e0a# }
aclmaker.pl: sent CR, received {
cs3mc-lab-e0a# }
aclmaker.pl: found Cisco prompt: cs3mc-lab-e0a#
aclmaker.pl: sending { show term | inc Len } to router...
aclmaker.pl: matched pattern#1: ^Length: (\d+) lines, Width: (\d+) columns
aclmaker.pl: null send string, skipping send...
aclmaker.pl: matched pattern#1: ^cs3mc-lab-e0a(\(\S+\))?#
aclmaker.pl: sending { terminal length 0 ! acl-boris.pl } to router...
aclmaker.pl: matched pattern#1: ^cs3mc-lab-e0a(\(\S+\))?#
aclmaker.pl: sending { terminal width  0 ! acl-boris.pl } to router...
aclmaker.pl: matched pattern#1: ^cs3mc-lab-e0a(\(\S+\))?#
aclmaker.pl: sending { show running-config ! downloading... } to router...
aclmaker.pl: failed to get match { ^cs3mc-lab-e0a(\(\S+\))?# } on command:
        show running-config ! downloading...
aclmaker.pl: sent closing commands { ^Z / terminal length 0 / terminal
width 80 }

Note that it matches the pattern for the router command line three
times, then sends "show running-config" and is looking for another
router prompt so it'll know where the end of the config output is.
When the user turned on Expect verbose debugging, he sent me this
output:

[...]
Waiting for new data (5 seconds)...
handle id(3): new data.
handle id(3): read 509 byte(s).

handle id(3): Does `...
+---------------------------------------------+\r\012        |
|\r\012        |     ********** W A R N I N G **********     |\r\012
|                                             |\r\012        |  This system
is private and is RESTRICTED   |\r\012        |  to authorized users only.
Unauthorized    |\r\012        |  attempts CAN BE TRACED, and those
|\r\012        |  responsible will be PROSECUTED.            |\r\012
|  If you are not authorized, PISS OFF! |\r\012        |
|\r\012
+---------------------------------------------+\r\012\r\012\r\012^C\r\012!
\r\012line con 0\r\012 exec-timeout 15 0\r\012 password 7
0123456789ABCD\r\012 login\r\012 transport input none\r\012line aux 0\r\012
exec-timeout 15 0\r\012 password 7 0123456789ABCD\r\012 login\r\012line vty
0 4\r\012 no exec\r\012 exec-timeout 15 0\r\012 no login\r\012 transport
input none\r\012!\r\012!\r\012end\r\012
\r\012cs3mc-lab-e0a#'
match:
  pattern #1: -re `^cs3mc-lab-e0a(\\(\S+\))?#'? No.

Waiting for new data (4 seconds)...
TIMEOUT

Well, there's the "\r\012cs3mc-lab-e0a#", the same thing that matched
previously. When I look at the debug output of the script when I use it,
it looks the same, except that in my environment the string is printed
as "\r\ncs3mc-lab-e0a#".

I don't think the problem is multi-line matching - my program doesn't
touch $Expect::Multiline_Matching and if I set it to 0 it fails on the
first match try.  However, the big difference between the early commands
that matched and the one that failed is that the latter produces hundreds
of lines of output, while the successful commands produced either 30-40
lines (the "show term") or none at all (the two "set term" commands) except
for the router's prompt.

Since I don't have access to the user's environment, I'm at a loss as
to how to debug this further.  Can anyone make suggestions on what to
tweak or what else to try?  If you want to look at the program, it's
over at:

   http://prdownloads.sourceforge.net/cosi-nms/aclmaker-perl-1.01.txt

Many thanks,

	-- Ed

[Expectperl-discuss] 'Ftp' acts different in Cygwin and Linux

[Chen leonard-a. <lia...@mo...>]

Hi,

When I try to automate 'ftp' under WINNT(CYGWIN_NT-4.0), I found it acts different from in Linux. Expect is not able to read any thing from 'ftp' in Cygwin. So, why? (the following is the script and logs.)

BRs,
Liang

#----------------------------------
Here's the perl script:
#----------------------------------
use Expect;
# Optional debugging, explained later.
$Expect::Debug=1;
$Expect::Exp_Internal=1;
$Expect::Log_Stdout=1; # On by default.
# Start the process.
$ftp_cmd="ftp";
($sh = Expect->spawn($ftp_cmd)) || die "Couldn't spawn $ftp_cmd, $!";
# wait for anything!
$sh->expect(undef );
#----------------------------------
Here's the log in Cygwin:
#----------------------------------
$ uname
CYGWIN_NT-4.0

God@LIANGCHEN ~/Perl/Tutorial
$ which ftp
/cygdrive/c/WINNT/system32/ftp

God@LIANGCHEN ~/Perl/Tutorial
$ perl -w ftp_expect4.pl
Spawned 'ftp'
        spawn id(3)
        Pid: 413
        Tty: /dev/tty0
        Expect::spawn('Expect', 'ftp') called at ftp_expect4.pl line 21
Starting EXPECT pattern matching...
        Expect::expect('Expect=GLOB(0xa213184)', undef) called at ftp_expect4.pl
 line 24
spawn id(3): beginning expect.
        Timeout: unlimited seconds.
        Current time: Fri Mar 15 09:27:10 2002
spawn id(3): list of patterns:

Waiting for new data (unlimited seconds)...

#----------------------------------
Here's the log in Linux:
#----------------------------------
Spawned 'ftp'
        spawn id(3)
        Pid: 1729
        Tty: /dev/pts/1
        Expect::spawn('Expect', 'ftp') called at ftp_expect4.pl line 21
Starting EXPECT pattern matching...
        Expect::expect('Expect=GLOB(0x82e3320)', undef) called at ftp_expect4.pl line 24
spawn id(3): beginning expect.
        Timeout: unlimited seconds.
        Current time: Thu Mar 14 20:28:06 2002
spawn id(3): list of patterns:

Waiting for new data (unlimited seconds)...
spawn id(3): new data.
spawn id(3): read 5 byte(s).
ftp> 
spawn id(3): Does `ftp> '
match:

Waiting for new data (unlimited seconds)...

[Expectperl-discuss] IO-TTy installation error on AIX

[Stamper, S. <Ste...@fo...>]

I'm just coming up to speed on PERL but have been using expect for years.  This  expectperl  tool looks might it will be wonderful - if I can get it installed!  

While trying to install  IO-Tty-0.97_01  I get the following error:

	/home/root/IO-Tty-0.97_01# perl Makefile.PL
	Now let's see what we can find out about your system
	(logfiles of failing tests are available in the conf/ dir)...

	ERROR: cannot run the configured compiler cc_r
	(see conf/compilerok.log).  Maybe you should build perl by yourself?

	/home/root/IO-Tty-0.97_01# gcc -v
	Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.0.1/specs
	Configured with: ./configure --enable-threads=aix --disable-nls
	Thread model: single
	gcc version 3.0.1
	/home/root/IO-Tty-0.97_01# 


	/home/root/IO-Tty-0.97_01# perl -v
	This is perl, v5.6.1 built for aix-thread


	/home/root/IO-Tty-0.97_01/conf# cat compilerok.c
	int main () { return 0; }

	/home/root/IO-Tty-0.97_01/conf# cat compilerok.log
	sh: cc_r:  not found.

	/home/root/IO-Tty-0.97_01/conf# oslevel
	4.3.3.0

I'm not a C person so any help would be great!

TIA
Steve Stamper

[Expectperl-discuss] ANNOUNCE: IO-Tty v1.00 and Expect v1.14

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

IO-Tty v1.00 and Expect v1.14 are now available from CPAN (when the 
packages have propagated) as well as from the project homepage at 
http://sourceforge.net/projects/expectperl/.

From the READMEs:

IO::Tty and IO::Pty provide an interface to pseudo tty's

To build this distribution, run

  perl Makefile.PL
  make
  make test
  make install

ALL BRAND NEW!!

I finally took the time to give the pty-allocation part a complete
overhaul.  Thanks to openssh and Xemacs teams for providing me with a
lot of inspiration through their own pty-allocation codes.

I also removed the spawn code, as this doesn't fit thematically in
here.  Look into 'try' or 'test.pl' to see how it is done by hand.
Problems with ackquiring a controlling terminal should also be fixed
and propagating terminal size changes is now supported.  Please read
the manpages, there is a lot of new stuff (e.g. IO::Tty::Constant).

Please note that pty creation is very system-dependend.  I am
beginning to get an overview, but there are a *lot* of different
systems out there.  If you have problems on your system, please send
me (<RGi...@cp...>) the output of a manual installation ('perl
Makefile.PL; make; make test;') and I'll see what I can deduce from
it.

Supported systems include Linux, Solaris, AIX, OSF, *BSD, IRIX, HP-UX
and finally Windows (under the Cygwin environment, see
http://sources.redhat.com/cygwin/).  See the IO::Tty manpage for a
detailed list.  I also compiled an overview table, find it in the
project pages document manager at SourceForge
(http://sourceforge.net/projects/expectperl/).

Sorry, ActiveState Perl is not supported, basically because there are
no pseudo-terminals under Windows.  If somebody from ActiveState reads
this and wants to work on it, please contact me, maybe we could use
the equivalent of pipes to emulate the behaviour.

If it's working on your system, please send me a short note with
details (version number, distribution, etc. 'uname -a' is a good
start) so I can get an overview.  Thanks!

See the ChangeLog and the docs for details.

Oh, and many thanks to all testers, without their support this project
would still be limited to a few systems that I have access to.  Thanks
also to SourceForge (http://sf.net) who is hosting this and many other
projects, their services have made development and support a real
pleasure.  If you intend to donate something to the Open Source cause,
think about lending them a machine for their compile farm!

Roland <RGi...@cp...>
2002-03-12


Expect.pm v1.14
===============

Expect requires the latest version of IO::Tty, also available from
CPAN.  IO::Stty has become optional but I'd suggest you also install
it.  If you use the highly recommended CPAN module, there is a
Bundle::Expect available that installs everything for you.

If you prefer manual installation, the usual

  perl Makefile.PL
  make
  make test
  make install

should work.  I finally started a testsuite for Expect, but it doesn't
really test anything deeper right now.  The problem is to find some
external program to use for generating reproducible output that is
available across all platforms.  Luckily, we can always use perl
itself...  Contributions to the testsuite are of course welcome.

Note that IO::Tty is very system-dependend.  It has been extensively
reworked and tested, but there still may be systems that have
problems.

The Perl Expect module was inspired more by the functionality of
Tcl/Expect than any previous Expect-like tool such as Comm.pl or
chat2.pl.

The Tcl version of Expect is a creation of Don Libes (li...@ni...)
and can be found at http://expect.nist.gov/.  Don has written an
excellent in-depth tutorial of Tcl/Expect, which is _Exploring
Expect_.  It is the O'Reilly book with the monkey on the front.  Don
has several references to other articles on the Expect web page.

I try to stay as close to Tcl/Expect in interface and semantics as
possible (so I can refer questions to the Tcl/Expect docu).
Suggestions for improvement are always welcome.

[Latest rumours have it that Don plans a rewrite of Expect as a
stand-alone library that can be easily embedded into various scripting
languages.]

There is now a FAQ section in the pod, complete with examples, so
please let me know if there's something you'd like to see answered
there that isn't.

There are two mailing lists available, expectperl-announce and
expectperl-discuss, at

  http://lists.sourceforge.net/lists/listinfo/expectperl-announce

and

  http://lists.sourceforge.net/lists/listinfo/expectperl-discuss


From the Changes file:
======================

! changed tests to check out pty behaviour (max. string length)

+ added various FAQ entries

+ added autoflush(1) to log_file

+ split 'new' and 'spawn' to be able to set slave pty params via stty
  before actually spawning the program

+ added raw_pty()

+ added notransfer()

+ added print_log_file(), send() now no longer prints to log file or 
stdout.

! spawn() now synchronizes child and parent, so exec errors are 
reported.

+ timeout handlers now also can exp_continue

+ added 'raw_pty' option, also setting master to raw if isatty()

+ added and corrected test for exit status; got rid of Test.pm

! use 'set_raw' instead of stty("raw"); IO::Stty now optional

+ updated docs & FAQs; explained how terminal sizes and SIGWINCH
  should be propagated

! fixed bug in log_file, parameter now gets set to undef.

! fixed select in interconnect, may return -1 if interrupted by signal.


Thanks to everybody who wrote to me, either with bug reports or
enhancement suggestions!

Roland Giersig (maintainer of Expect.pm, IO::Tty, IO::Stty, 
Tie::Persistent)
RGi...@cp...
2002-03-12

--
RGi...@cp...