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

RE: [Expectperl-discuss] 2.4.14 Linux Kernel

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

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

RE: [Expectperl-discuss] -notransfer ?

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

  I'm driving a screen-oriented menu interface.  It's fairly easy to
control, but I'd like to be able to do things like:

sub go_to_main_menu
{
  $expect->send(whatever's needed to get there);
  $expect->expect(10, -notransfer, "Main menu prompt> ");
}

# This procedure enters the "Data" menu.  A prerequisite for running this
routine
# is that the session must be in the main menu.
sub datamenu
{
  $expect->expect(2,
                  ["Main menu prompt> " => sub { ... }],
                  timeout => \&handle_wrong_menu_exception);
}

  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.

  BTW, just because you might find it interesting, I'm subclassing Expect.
Fun! :)  (I'd never succesfully worked with a glob reference until I looked
into Expect.pm.  I never could figure it out.)

jdb

> -----Original Message-----
> From: Roland Giersig [mailto:RGi...@a1...]
> Sent: Friday, December 07, 2001 3:56 AM
> To: Blackstone J. David
> Cc: exp...@li...
> Subject: Re: [Expectperl-discuss] -notransfer ?
> 
> 
> >  Is there a way to do what the -notransfer option to the expect 
> > command in TCL expect does?
> 
> No.  As I'm not familiar with that option, I cannot say if it is easy 
> to implement or not.  From a quick glance on the manpage I'd say its 
> easy, but the semantics and the usefulness is not quite clear.  One 
> could always combine patterns to get the same effect.
> 
> Roland
> --
> RGi...@cp...
> 

RE: [Expectperl-discuss] RE: problems with spawn

[Maloney, G. <ger...@in...>]

Thanks
	it seem that there also was a small issue with telnet'ing to an
win2k machine , where it asks for the Terminal emulation which it needs to
display the stdout.

So when I added the expect and sends for that and the interactive() , it
works.

Cheers G.

-----Original Message-----
From: Roland Giersig [mailto:RGi...@a1...]
Sent: Friday, December 07, 2001 9:13 AM
To: Maloney Gerard
Cc: exp...@li...
Subject: Re: [Expectperl-discuss] RE: problems with spawn


> In a cywin window or even in a DOS box,  I execute the following , 
> but the
> spawn command seems to fork off a new session which I cannot see.

Yes, that's intended behaviour.  You can control that session by 
sending to it and expecting on its output.

> How can I get it to work so that the telnet session is active in 
> the current window ?

Use interact().  This connects the process with the scripts stdin/out 
(your terminal).  BTW, storing passwords in cleartext has security 
implications and should be avoided wherever possible.  Maybe you could 
use ssh instead?

Hope this helps,

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

Re: [Expectperl-discuss] -notransfer ?

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

>  Is there a way to do what the -notransfer option to the expect 
> command in TCL expect does?

No.  As I'm not familiar with that option, I cannot say if it is easy 
to implement or not.  From a quick glance on the manpage I'd say its 
easy, but the semantics and the usefulness is not quite clear.  One 
could always combine patterns to get the same effect.

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

Re: [Expectperl-discuss] RE: problems with spawn

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

> In a cywin window or even in a DOS box,  I execute the following , 
> but the
> spawn command seems to fork off a new session which I cannot see.

Yes, that's intended behaviour.  You can control that session by 
sending to it and expecting on its output.

> How can I get it to work so that the telnet session is active in 
> the current window ?

Use interact().  This connects the process with the scripts stdin/out 
(your terminal).  BTW, storing passwords in cleartext has security 
implications and should be avoided wherever possible.  Maybe you could 
use ssh instead?

Hope this helps,

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

Re: [Expectperl-discuss] 2.4.14 Linux Kernel

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

> Is anyone using Expect on a 2.4.x Linux kernel? I have a script 
> that runs fine on a 2.2.16 machine, but will not run a 2.4.14 
> machine. When I have the script output what it's doing, it looks 
> like it gets to the point where it actually does what I need, but 
> it doesn't actually do what I expect it to.

That's not very coherent.  Could you be a little bit more explicit and 
describe, what it's supposed to do and where it fails?  Output from 
$Expect::Exp_Internal=1 will also help.

> I did a make test for the IO-Tty and Expect packages and 
> everything checked out ok. Anohter odd thing is that a native Tcl-
> Expect script also will not run on the 2.4.14 machine but will run 
> on the 2.2.16 machine.

There might be an issue with the ptys, but again, more data is needed.

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

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

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

> 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...

Re: [Expectperl-discuss] Expect - spawn failure

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

>     "cannot open a pty: cannot grantpt() at (my script location) -
> Error String: (Not enough space).
> 
> I too have tried to run this out of a shell and the response back 
> in the
> shell is "
>     "Cannot fork: Not enough space at
> /opt/perl5/lib/site_perl/5.005/Expect.pm line 98, <INfile> chunk 129

Nothing strange here, in both cases a fork fails (grantpt() spawns a 
suid prog) due to not enough memory available on the machine, so from a 
software point of view this is a correct response.  Now why your 
machine doesn't have enough memory, that's a completely different 
issue...

> I'm really puzzled about the "space" issue as I've plenty of space
> available in all file systems.

No, not file systems, memory.  Maybe there are some huge processes 
running?  Swap space too small?

Hope this helps,

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

[Expectperl-discuss] -notransfer ?

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

  Is there a way to do what the -notransfer option to the expect command in
TCL expect does?

jdb

[Expectperl-discuss] Expect - spawn failure

[<Ron...@de...>]

I've successfully used Expect in a number of scripts but I've recently
encountered a problem whereby the spawn initiated from the Expect fails.
The configuration is HPUX 10.2 running Perl 5.005_03 with Expect 1.12, Tty
0.05 and Pty 0.02. To isolate the problem I've "eval-ed" the spawn and the
$@ value returned from the spawn, (e.g. eval{$tn=Expect-> spawn("telnet
$HostID);}  lists the following:
     "cannot open a pty: cannot grantpt() at (my script location) - Error
String: (Not enough space).

I too have tried to run this out of a shell and the response back in the
shell is "
     "Cannot fork: Not enough space at
/opt/perl5/lib/site_perl/5.005/Expect.pm line 98, <INfile> chunk 129

I'm really puzzled about the "space" issue as I've plenty of space
available in all file systems. Could anyone possible offer me any insight
into what I might be doing incorrectly? Thanks for any and all responses.

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

[John P. <joh...@in...>]

Has anyone re-written original dislocate script?  If not, I will cook
one up and submit it as an example for the tutorial section.
The old dislocate (it's been a while since I have used it) had a problem
choking on large volume's of data output from the process being ran.
 
 
Thanks!
John

[Expectperl-discuss] 2.4.14 Linux Kernel

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

Is anyone using Expect on a 2.4.x Linux kernel? I have a script that runs fine on a 2.2.16 machine, but will not run a 2.4.14 machine. When I have the script output what it's doing, it looks like it gets to the point where it actually does what I need, but it doesn't actually do what I expect it to.

I did a make test for the IO-Tty and Expect packages and everything checked out ok. Anohter odd thing is that a native Tcl-Expect script also will not run on the 2.4.14 machine but will run on the 2.2.16 machine.

-Kevin

[Expectperl-discuss] RE: problems with spawn

[Maloney, G. <ger...@in...>]

Hello
	I installed cgywin on Win 2K and using the latest version of
IO-Tty-0.92_03.tar.gz recommended by Roland I successfully built and
installed Expect-1_12.

In a cywin window or even in a DOS box,  I execute the following , but the
spawn command seems to fork off a new session which I cannot see.

How can I get it to work so that the telnet session is active in the current
window ?

Thanks G. 

#
# Version 1.0 Date 03.12.01

#
#############


# include files
use Expect;

$callgen= Expect->spawn("telnet x.x.x.x");
$callgen->log_stdout(0);
$callgen->expect(10,'-re',"Login:");
$callgen->send("ger\n");
$callgen->expect(10,'-re',"Password:");
$callgen->send("12345\n");

RE: [Expectperl-discuss] using disconnect

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

  Yes, there is, but it's a function of Perl itself rather than Expect.pm.
I recommend you check two things:

* the comp.unix.programmer FAQ question about "How do I create a daemon?"
* the Proc::Daemon module, which will do all the things you will read about
in the FAQ in one easy step

jdb

> -----Original Message-----
> From: ksc...@mi... [mailto:ksc...@mi...]
> Sent: Monday, December 03, 2001 4:29 PM
> To: exp...@li...
> Subject: [Expectperl-discuss] using disconnect
> 
> 
> Let's say I have the following Expect script:
> 
> #!/usr/bin/expect -f
> if {[fork] != 0} exit
> disconnect
> spawn command
> # do something
> 
> Is there an equivalent way to perform the "disconnect" command found
> in the Tcl-based Expect?
> 
> Thanks,
> -Kevin
> 
> 
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

[Expectperl-discuss] using disconnect

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

Let's say I have the following Expect script:

#!/usr/bin/expect -f
if {[fork] != 0} exit
disconnect
spawn command
# do something

Is there an equivalent way to perform the "disconnect" command found
in the Tcl-based Expect?

Thanks,
-Kevin

Re: [Expectperl-discuss] @Expect::(Before|After)_List

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

> > >  It would be cool if in addition to the package variables
> > > (affecting all expect() calls), there was a per-object list as well.
> >
> > Not without a complete rewrite. :-)
> 
>   Well, right now it pretty much says: "if @Expect::Before_List then
> _multiexpect(@Expect::Before_List)."  What if it said: "@before_list =
> (@Expect::Before_List, @{${*$self}{before_list}}); if @before_list then
> _multiexpect @before_list"?  At any rate, just musing.

Unfortunately it isn't that easy.  This would only work for one object, but not
if you want to expect on several objects at once via '-i'.  It most certainly 
could be done in some way but would add a lot of complexity in terms of
semantics due to hidden parameters.  If you want such a thing, you are always
free to order your pattern-callback-list the way you want.

>   Cool!  That's one of the neatest things I've heard in awhile.  I never
> figured that would happen, because he seemed to like TCL so much.  So did I,
> originally, but life changed. :)

I still like Tcl, but only for its original intent, namely bringing an 
easy-to-understand-and-learn config scripting language to any application
with a minimum of fuss.  But I don't want to write large applications in
it anymore due to the quoting hell you get into when you want to smuggle
regexps with variables in them through the parser.  And the parsing-at-runtime
didn't help either...

BTW, if anybody can think of requirements for the Expect rewrite, feel free 
to throw them my way, I'll collect and forward them.  And yes, using the 
scripting languages regexp engine is already on the top of the list...

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

[Expectperl-discuss] Clearing the buffer

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

  I learned this after much trial and error and thought I would share in
case someone else wants to know.  I figure someone will also point out a
much easier way I should have considered first.

  In TCL expect, you can clear the current buffer with
expect *
  (At least, I think you could.  The code I'm translating immediately
follows that statement with "expect -re .*".  Both statements seem to be
necessary for some reason, but the purpose is to clear the buffer.)

  To clear the buffer with Expect.pm, you can
$expect->expect(0, '-re', qr/(.|\n)+/);

  The \n is necessary (and tripped me up quite painfully) because . doesn't
match \n.  (I used to know that, but those brain cells apparently burned up
some while back.)

  $expect->expect(0) didn't seem to clear the buffer as I originally
expected.

jdb

RE: [Expectperl-discuss] @Expect::(Before|After)_List

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

> -----Original Message-----
> From: Roland Giersig [mailto:RGi...@a1...]
> Sent: Friday, November 30, 2001 10:24 AM
> To: Blackstone J. David
> Cc: exp...@li...
> Subject: Re: [Expectperl-discuss] @Expect::(Before|After)_List
> 
> 
> >  I note the presence of undocumented package variables 
> > @Before_List and
> > @After_List, presumably for expect_after and expect_before 
> > functionality,like the original TCL expect.  Neat!
> 
> Yup, my goal is (was) to model the Perl version as close as possible 
> after the Tcl version.
> 
> >  It would be cool if in addition to the package variables 
> > (affecting all expect() calls), there was a per-object list as well.
> 
> Not without a complete rewrite. :-)

  Well, right now it pretty much says: "if @Expect::Before_List then
_multiexpect(@Expect::Before_List)."  What if it said: "@before_list =
(@Expect::Before_List, @{${*$self}{before_list}}); if @before_list then
_multiexpect @before_list"?  At any rate, just musing.

> BTW, Don Libes is planning a rewrite of the original Expect 
> and one of 
> the goals is to create a lib that can be easily integrated into all 
> kinds of scripting languages.  I already contacted him and 
> will see to 
> it that it works with Perl.  No timeframe has been discussed yet, so 
> don't hold 'yer breath.

  Cool!  That's one of the neatest things I've heard in awhile.  I never
figured that would happen, because he seemed to like TCL so much.  So did I,
originally, but life changed. :)

jdb

Re: [Expectperl-discuss] @Expect::(Before|After)_List

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

>  I note the presence of undocumented package variables 
> @Before_List and
> @After_List, presumably for expect_after and expect_before 
> functionality,like the original TCL expect.  Neat!

Yup, my goal is (was) to model the Perl version as close as possible 
after the Tcl version.

>  It would be cool if in addition to the package variables 
> (affecting all expect() calls), there was a per-object list as well.

Not without a complete rewrite. :-)

BTW, Don Libes is planning a rewrite of the original Expect and one of 
the goals is to create a lib that can be easily integrated into all 
kinds of scripting languages.  I already contacted him and will see to 
it that it works with Perl.  No timeframe has been discussed yet, so 
don't hold 'yer breath.  I'll take note of that requirement and see if 
it's possible to design that in without too many backflips.

Cheers!

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

[Expectperl-discuss] @Expect::(Before|After)_List

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

  I note the presence of undocumented package variables @Before_List and
@After_List, presumably for expect_after and expect_before functionality,
like the original TCL expect.  Neat!

  It would be cool if in addition to the package variables (affecting all
expect() calls), there was a per-object list as well.

jdb

Re: RE: [Expectperl-discuss] errors when installing io::tty under cyg win

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

>  I note that the new IO::Tty is "based on ideas from openssh and 
> Xemacs."Any ideas from Libes' original Expect in there?  Have the 
> openssh and Xemacs
> guys figured out a better way than he did or did they just borrow 
> from his method?  How do all these different approaches compare?
> 
>  I'm just eaten up with curiosity. :)

Then you need a speedy answer! :-)

For pty allocation, I used ideas from openssh and Xemacs as they have a 
more modern approach.  A lot of systems have incorporated some kind of 
cloning device in the meantime that weren't there when Tcl/Expect was 
developed.  I concentrated on an idea from Xemacs, namely just figuring 
out what possibilities (libs/devices) are there and then trying all of 
them in order until one succeeds, the last one being the standard BSD-
style technique of opening all /dev/pty*s one after another until an 
open succeeds.

I collected several methods of allocating a pty from several sources. 
These are:

  openpty()
  _getpty()
  getpt()
  /dev/ptmx
  /dev/ptym/clone
  /dev/ptc
  /dev/ptmx_bsd

If anybody knows about other methods, please let me know.

Now what could be a problem is the pty setup: I use grantpt() and 
unlockpt() and push appropriate stream modules via ioctl, but there 
could be others necessary, esp. on older systems.  The problem is that 
I can only rely on information in manpages etc. that I look up via 
Google, so I'm flying by instruments, pestering clients to get test 
results.  

What I used from Tcl/Expect was the method how spawn() works, namely 
using pipes to synchronize the parent with the forked child until the 
child has set up the pty, passing up a possible exec() error on the 
fly. Quite nifty!

Any more questions?

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

RE: [Expectperl-discuss] errors when installing io::tty under cyg win

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

> BTW, there is a new version available that has a much improved pty 
> allocation.  It still has beta status, as I first want to 
> test it on as 
> much different systems as possible, but if you want you could try it 
> out.  Find it on CPAN under 
> R/RG/RGIERSIG/IO-Tty-0.92_03.tar.gz.  There 
> is also a matching Expect version there, Expect-1.13_01.tar.gz.

  I note that the new IO::Tty is "based on ideas from openssh and Xemacs."
Any ideas from Libes' original Expect in there?  Have the openssh and Xemacs
guys figured out a better way than he did or did they just borrow from his
method?  How do all these different approaches compare?

  I'm just eaten up with curiosity. :)

jdb

RE: [Expectperl-discuss] errors when installing io::tty under cyg win

[Maloney, G. <ger...@in...>]

Morning Roland
	I though that if it failed to find the necessary file that the
Makefile would be incomplete. So I did include the other errors, but here
they are 

When I do a make I get the following

gcc -c  -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing 
-I/usr/local/include -DUSEIMPORTLIB -O2   -DVERSION=\"0.05\"
-DXS_VERSION=\"0.05\" 
-I/usr/lib/perl5/5.6.1/cygwin-multi/CORE -DHAS_TTYNAME Tty.cygwin-multi/CORE
-DHAS_TTYNAME Tty.c
Tty.xs:111: Invalid token in expression
Tty.xs:242: Invalid token in expression
make: *** [Tty.o] Error 1

and the make test yields the same error

$ perl test.pl
Using /cygdrive/c/temp/IO-Tty-0.05/blib
Can't load '/usr/bin/Tty' for module IO::Tty: dlopen: Win32 error 126 at
/usr/li
b/perl5/5.6.1/cygwin-multi/DynaLoader.pm line 206.
 at /cygdrive/c/temp/IO-Tty-0.05/blib/lib/IO/Tty.pm line 25
Compilation failed in require at
/cygdrive/c/temp/IO-Tty-0.05/blib/lib/IO/Pty.pm
 line 7.
BEGIN failed--compilation aborted at
/cygdrive/c/temp/IO-Tty-0.05/blib/lib/IO/Pt
y.pm line 7.
Compilation failed in require at test.pl line 5.
BEGIN failed--compilation aborted at test.pl line 5.


So there seem to have a build problem .

G.
-----Original Message-----
From: Roland Giersig [mailto:RGi...@a1...]
Sent: Wednesday, November 28, 2001 10:15 AM
To: Maloney Gerard
Cc: 'exp...@li...'
Subject: Re: [Expectperl-discuss] errors when installing io::tty under
cygwin


>        I am experiencing difficulties with getting io:tty 
> installed on cygwin, which I need to get expect to work.

What kind of difficulties?  Does it not compile?  Do the tests fail?

> I checked the internet and found information about binutil , which I
> downloaded from cygwin. However following that I now get this
> 
> $ perl makefile.pl
> Looking for ttyname()... found.
> Looking for libutil.h... not found.
> Looking for util.h... not found.
> Looking for pty.h... not found.
> Looking for openpty()... not found.
> DEFINE = -DHAS_TTYNAME
> Writing Makefile for IO::Tty

No problem so far.  If those libraries were crucial, no Makefile would 
be written.  Go ahead and do a 'make' and 'make test', it should work.

BTW, there is a new version available that has a much improved pty 
allocation.  It still has beta status, as I first want to test it on as 
much different systems as possible, but if you want you could try it 
out.  Find it on CPAN under R/RG/RGIERSIG/IO-Tty-0.92_03.tar.gz.  There 
is also a matching Expect version there, Expect-1.13_01.tar.gz.

Hope this helps,

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

Re: [Expectperl-discuss] errors when installing io::tty under cygwin

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

>        I am experiencing difficulties with getting io:tty 
> installed on cygwin, which I need to get expect to work.

What kind of difficulties?  Does it not compile?  Do the tests fail?

> I checked the internet and found information about binutil , which I
> downloaded from cygwin. However following that I now get this
> 
> $ perl makefile.pl
> Looking for ttyname()... found.
> Looking for libutil.h... not found.
> Looking for util.h... not found.
> Looking for pty.h... not found.
> Looking for openpty()... not found.
> DEFINE = -DHAS_TTYNAME
> Writing Makefile for IO::Tty

No problem so far.  If those libraries were crucial, no Makefile would 
be written.  Go ahead and do a 'make' and 'make test', it should work.

BTW, there is a new version available that has a much improved pty 
allocation.  It still has beta status, as I first want to test it on as 
much different systems as possible, but if you want you could try it 
out.  Find it on CPAN under R/RG/RGIERSIG/IO-Tty-0.92_03.tar.gz.  There 
is also a matching Expect version there, Expect-1.13_01.tar.gz.

Hope this helps,

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

[Expectperl-discuss] errors when installing io::tty under cygwin

[Maloney, G. <ger...@in...>]

Hello
	I am experiencing difficulties with getting io:tty installed on
cygwin, which I need to get expect to work.

I checked the internet and found information about binutil , which I
downloaded from cygwin. However following that I now get this

$ perl makefile.pl
Looking for ttyname()... found.
Looking for libutil.h... not found.
Looking for util.h... not found.
Looking for pty.h... not found.
Looking for openpty()... not found.
DEFINE = -DHAS_TTYNAME
Writing Makefile for IO::Tty

any ideas

Gerard