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

Re: [Expectperl-discuss] spawn hanging on darwin

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

> > This leads me to the conclusion that the close-on-exit is broken on
> > Darwin.
> >
> > Workaround: add a 'sleep 1' to the spawn command,
> > i.e. spawn("someprog; sleep 1").
> 
> Let me make sure I understand the syntax you're proposing -- tack on
> "; sleep 1" to spawn's first argument?  To use an example from
> Crypt:GPG, this
> 
> my $expect = Expect->spawn ("$self->{GPGBIN}", @opts, '-o-', '--sign',
> $armor, $detach, '--default-key', $self->{SECRETKEY}, $tmpnam);
> 
> becomes this:
> 
> my $expect = Expect->spawn ("$self->{GPGBIN}; sleep 1", @opts, '-o-',
> '--sign', $armor, $detach, '--default-key', $self->{SECRETKEY},
> $tmpnam);

No, add it as the last statement:

  my $expect = Expect->spawn ("$self->{GPGBIN} @opts -o- \
  --sign $armor $detach --default-key $self->{SECRETKEY} \
  $tmpnam; sleep 1");

This will pass everything to the shell, so you have to take care of 
shell metachars in your arguments, but that's seldom a problem.

I added such a 'sleep' statement to all spawns in test.pl and now all 
tests pass (except those I added to specifically test for the bug).  

Have you tried the Crypt::GPG tests on a different platform?  If you 
don't have access locally, I can recommend the SourceForge compile 
farm.  It is important to try out to see if the problem is system-
dependend or not.  If you can reproduce the problem on a different 
architecture, then we have a pure application problem...

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

Re: [Expectperl-discuss] spawn hanging on darwin

[Nathaniel I. <nd...@bu...>]

On Thu, Apr 04, 2002 at 12:15:16PM +0200, RGi...@a1... wrote:

> Interesting, I also encountered that error during my test runs, but it 
> was only temporary, when I reran the test, it worked.  If you can 
> reproduce it consistently, please uncomment the '$Expect::Exp_Internal 
> = 1' line in test.pl and rerun the test.  It will probably vanish then, 
> just as Murphy predicts.

I could reproduce it consistently, so I uncommented that line, and it
failed again -- unfortunately I didn't save that output, and when I
reran the test with the line uncommented, it completed the test suite.
When it was done, however, the only test it had failed was 15, which
was the failure in my original message.  Here's the output:

Continuing expect, restarting timeout...

spawn id(4): Does `\r\n'
match:
  pattern #1: -re `Begin'? No.
  pattern #2: -re `End'? No.
  pattern #3: -eof `'? No.

Waiting for new data (1 seconds)...
TIMEOUT
Calling timeout function ARRAY(0x41c294)...
Waiting for new data (1 seconds)...
TIMEOUT
Calling timeout function ARRAY(0x41c294)...
Waiting for new data (1 seconds)...
TIMEOUT
Calling timeout function ARRAY(0x41c294)...
Waiting for new data (1 seconds)...
TIMEOUT
Calling timeout function ARRAY(0x41c294)...
Waiting for new data (1 seconds)...
EOF
not ok 15
# Test failed at test.pl line 83.
Returning from expect with TIMEOUT or EOF

> This leads me to the conclusion that the close-on-exit is broken on
> Darwin.
>
> Workaround: add a 'sleep 1' to the spawn command,
> i.e. spawn("someprog; sleep 1").

Let me make sure I understand the syntax you're proposing -- tack on
"; sleep 1" to spawn's first argument?  To use an example from
Crypt:GPG, this

my $expect = Expect->spawn ("$self->{GPGBIN}", @opts, '-o-', '--sign',
$armor, $detach, '--default-key', $self->{SECRETKEY}, $tmpnam);

becomes this:

my $expect = Expect->spawn ("$self->{GPGBIN}; sleep 1", @opts, '-o-',
'--sign', $armor, $detach, '--default-key', $self->{SECRETKEY},
$tmpnam);

There are ten calls to spawn in Crypt::GPG, and I modified them all as
shown.  It still hangs in test 11, apparently with the same symptoms:

http://bumppo.net/expect/debug-trace-2.txt

Thanks for all your effort.

  -nat

Re: [Expectperl-discuss] spawn hanging on darwin

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

I did some further investigations and have come to the conclusion that =

Darwin has a severe bug=3A

 When a spawned program exits=2C the master immediately gets EOF and all =

characters that should have been queued inside the pty are lost=2E

 When the spawned program closes the pty before exiting=2C no characters =

are lost=2E

This leads me to the conclusion that the close-on-exit is broken on =

Darwin=2E

Workaround=3A add a =27sleep 1=27 to the spawn command=2C i=2Ee=2E spawn(=
=22someprog=3B =

sleep 1=22)=2E

I don=27t know if this helps with Crypt=3A=3APGP=2C but it=27s a first st=
ep=2E

Roland
--
RGiersig=40cpan=2Eorg

----- Urspr=FCngliche Nachricht -----
Von=3A RGiersig=40a1=2Enet
Datum=3A Donnerstag=2C April 4=2C 2002 12=3A15 pm
Betreff=3A Re=3A =5BExpectperl-discuss=5D spawn hanging on darwin

=3E =3E Crypt=3A=3AGPG still failed=2C and when I went to re-run
=3E =3E Expect=27s test suite=2C just to see what would happen=2C I got t=
his=3A
=3E =3E =

=3E =3E =24 make test =

=3E =3E PERL=5FDL=5FNONLAZY=3D1 /usr/bin/perl -Iblib/arch -Iblib/lib
=3E =3E -I/System/Library/Perl/darwin -I/System/Library/Perl test=2Epl 1=2E=
=2E36
=3E =3E =

=3E =3E Basic tests=2E=2E=2E
=3E =3E =

=3E =3E ok 1
=3E =3E Use of uninitialized value in numeric eq (=3D=3D) at test=2Epl li=
ne 37=2E
=3E =3E not ok 2
=3E =3E =23 Test failed at test=2Epl line 22=2E
=3E =3E Died at test=2Epl line 22=2E
=3E =3E make=3A *** =5Btest=5Fdynamic=5D Error 255
=3E =3E =

=3E =3E That=27s after make clean=3B perl Makefile=2EPL=3B make=3B of cou=
rse=2E  I
=3E =3E repeated this failure on two systems=2C identically=2E
=3E =

=3E Interesting=2C I also encountered that error during my test runs=2C =

=3E but it =

=3E was only temporary=2C when I reran the test=2C it worked=2E  If you c=
an =

=3E reproduce it consistently=2C please uncomment the =

=3E =27=24Expect=3A=3AExp=5FInternal =

=3E =3D 1=27 line in test=2Epl and rerun the test=2E  It will probably va=
nish =

=3E then=2C =

=3E just as Murphy predicts=2E
=3E =

=3E I will continue to investigate=2E=2E=2E
=3E =

=3E Roland
=3E --
=3E RGiersig=40cpan=2Eorg
=3E =

=3E =

=3E =

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

=3E 

Re: [Expectperl-discuss] spawn hanging on darwin

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

> Crypt::GPG still failed, and when I went to re-run
> Expect's test suite, just to see what would happen, I got this:
> 
> $ make test 
> PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib
> -I/System/Library/Perl/darwin -I/System/Library/Perl test.pl 1..36
> 
> Basic tests...
> 
> ok 1
> Use of uninitialized value in numeric eq (==) at test.pl line 37.
> not ok 2
> # Test failed at test.pl line 22.
> Died at test.pl line 22.
> make: *** [test_dynamic] Error 255
> 
> That's after make clean; perl Makefile.PL; make; of course.  I
> repeated this failure on two systems, identically.

Interesting, I also encountered that error during my test runs, but it 
was only temporary, when I reran the test, it worked.  If you can 
reproduce it consistently, please uncomment the '$Expect::Exp_Internal 
= 1' line in test.pl and rerun the test.  It will probably vanish then, 
just as Murphy predicts.

I will continue to investigate...

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

Re: [Expectperl-discuss] spawn hanging on darwin

[Nathaniel I. <nd...@bu...>]

On Thu, Apr 04, 2002 at 09:06:32AM +0200, RGi...@a1... wrote:

> First of all, what version of IO-Tty and Expect are you using?  I just 
> tried the latest versions (v1.02 and v1.15) on SourceForges compile 
> farm and found that IO-Tty tests OK while Expect fails on test 31 line 
> 284, which tests the controlling terminal, but this can only be a minor 
> bug as the test for a controlling terminal passes in IO-Tty.  I'll look 
> into that.  BTW, that tests ran on Darwin Kernel 5.3.

I had IO::Tty 1.00 and Expect 1.15, with the same kernel version (it
corresponds to Mac OS X 10.1.3).  I upgraded IO::Tty to 1.0.2, which
passed its 4 tests.  Crypt::GPG still failed, and when I went to re-run
Expect's test suite, just to see what would happen, I got this:

$ make test 
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib
-I/System/Library/Perl/darwin -I/System/Library/Perl test.pl 1..36

Basic tests...

ok 1
Use of uninitialized value in numeric eq (==) at test.pl line 37.
not ok 2
# Test failed at test.pl line 22.
Died at test.pl line 22.
make: *** [test_dynamic] Error 255

That's after make clean; perl Makefile.PL; make; of course.  I
repeated this failure on two systems, identically.

  -nat

Re: [Expectperl-discuss] spawn hanging on darwin

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

> Expect builds on multiple Mac OS X systems here with one error in the
> test suite, but Crypt::GPG hangs in its test suite, and a trace
> indicates that it's halting in Expect's spawn method.  I would
> appreciate any help getting these modules functional, or figuring out
> what's wrong.

First of all, what version of IO-Tty and Expect are you using?  I just 
tried the latest versions (v1.02 and v1.15) on SourceForges compile 
farm and found that IO-Tty tests OK while Expect fails on test 31 line 
284, which tests the controlling terminal, but this can only be a minor 
bug as the test for a controlling terminal passes in IO-Tty.  I'll look 
into that.  BTW, that tests ran on Darwin Kernel 5.3.

> The trace from Crypt::GPG's test suite is available here:

Hmm, the spawn seems to hang on exec synchronisation, which is fishy, 
as the test suite contains a test for that...

Anyway, please check that you are using the latest versions.

Cheers!

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

[Expectperl-discuss] spawn hanging on darwin

[Nathaniel I. <nd...@bu...>]

I'm trying to get Crypt::GPG working under darwin/Mac OS X, and
Crypt::GPG relies on Expect.pm.

Expect builds on multiple Mac OS X systems here with one error in the
test suite, but Crypt::GPG hangs in its test suite, and a trace
indicates that it's halting in Expect's spawn method.  I would
appreciate any help getting these modules functional, or figuring out
what's wrong.

The error in Expect is not one that disclaims its importance, so I don't
know whether to take it seriously:

    ok 14
    EOF
    not ok 15
    # Test failed at test.pl line 83.

The trace from Crypt::GPG's test suite is available here:

    http://bumppo.net/expect/debug-trace.txt
    
Thanks for any assistance.

  -nat

Re: [Expectperl-discuss] Program won't work on new system

[Hal V. <ha...@th...>]

To those who have responded -- thanks.

I had tried a chmod -R to change the mod on all the library files.  It didn't 
work -- but then, that was early in the morning, after 4 hours of sleep.

I tried it again after someone else suggested it.  It worked.  Maybe I just 
wasn't awake enough to pay attention when I did it at first.

Thanks!

Hal

On Monday 01 April 2002 09:44 am, you wrote:
> I have a program that uses Expect.  Everything has been working fine while
> I have been running it on my own system (which is part of a lan).
>
> I am preparing a system that will go in a client's office.  It's running
> Mandrake 8.2 and I set the security level at Paranoid (I don't want to be
> the one at fault if anything happens to their lan!).  I copied the program
> over to their system (using sneaker-net and a floppy).  I had to go in as
> root to compile and add all the modules (Expect, Stty, Pty).  Then I
> changed the permissions on the perl library files for global read.  Now
> when I run the program as root, it works, but when I run it as a "normal"
> user, I get "not-found" errors (exact text included at bottom).  I've made
> sure the stty.* and Tty* files have had their permissions changed (same
> with Expect), so they can be read by all.
>
> What am I not doing?  Is there another file I need to change the
> permissions on?  I would think so, since root has no problem running this
> program.
>
> Thanks!
>
> Hal
>
> Text of error:
>
> Can't locate loadable object code for module IO::Tty in @INC (@INC
> contains: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1
> /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1
> /usr/lib/perl5/site_perl .) at
> /usr/lib/perl5/site_perl/5.6.1/i386-linux/IO/Tty.pm line 28.
> Compilation failed in require at
> /usr/lib/perl5/site_perl/5.6.1/i386-linux/IO/Pty.pm line 7.
> BEGIN failed--compilation aborted at
> /usr/lib/perl5/site_perl/5.6.1/i386-linux/IO/Pty.pm line 7.
> Compilation failed in require at /usr/lib/perl5/site_perl/5.6.1/Expect.pm
> line 22.
> BEGIN failed--compilation aborted at
> /usr/lib/perl5/site_perl/5.6.1/Expect.pm line 22.
> Compilation failed in require at ./fetch.pl line 100
> BEGIN failed--compilation aborted at ./fetch.pl line 100
>
> (line 100 in ./fetch.pl is "use Expect;" and presented no problems on the
> old system)
>
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss

Re: [Expectperl-discuss] Program won't work on new system

[Patrick N. <pn...@te...>]

Could it be as simple as checking the path environment variable?

Patrick Naber
pn...@te...

Re: [Expectperl-discuss] Program won't work on new system

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

>  Then I changed the
> permissions on the perl library files for global read.  Now when I run the
> program as root, it works, but when I run it as a "normal" user, I get
> "not-found" errors (exact text included at bottom).  I've made sure the
> stty.* and Tty* files have had their permissions changed (same with Expect),
> so they can be read by all.

You problably forgot to change the permissions on all the intermediate library dirs...

Hope this helps,

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

Re: [Expectperl-discuss] Program won't work on new system

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

On Mon, Apr 01, 2002 at 09:44:12AM -0500, Hal Vaughan wrote:
> I have a program that uses Expect.  Everything has been working fine while I 
> have been running it on my own system (which is part of a lan).
> 
> I am preparing a system that will go in a client's office.  It's running 
> Mandrake 8.2 and I set the security level at Paranoid (I don't want to be the 
> one at fault if anything happens to their lan!).  I copied the program over 
> to their system (using sneaker-net and a floppy).  I had to go in as root to 
> compile and add all the modules (Expect, Stty, Pty).  Then I changed the 
> permissions on the perl library files for global read.  Now when I run the 
> program as root, it works, but when I run it as a "normal" user, I get 
> "not-found" errors (exact text included at bottom).  I've made sure the 
> stty.* and Tty* files have had their permissions changed (same with Expect), 
> so they can be read by all.
> 
> What am I not doing?  Is there another file I need to change the permissions 
> on?  I would think so, since root has no problem running this program.
> 
> Thanks!
> 

	If I had to guess I'd say that your root user probably has a paranoid
umask of 077 or similar. I would check the permissions of
/usr/lib/perl5/site_perl/ and make sure everything is readable by other,
or just run a blanket chmod -R og+rx /usr/lib/perl5/site_perl/. That should
be safe unless you've installed modules with embedded passwords or other
such silliness.

	Austin

[Expectperl-discuss] Program won't work on new system

[Hal V. <ha...@th...>]

I have a program that uses Expect.  Everything has been working fine while I 
have been running it on my own system (which is part of a lan).

I am preparing a system that will go in a client's office.  It's running 
Mandrake 8.2 and I set the security level at Paranoid (I don't want to be the 
one at fault if anything happens to their lan!).  I copied the program over 
to their system (using sneaker-net and a floppy).  I had to go in as root to 
compile and add all the modules (Expect, Stty, Pty).  Then I changed the 
permissions on the perl library files for global read.  Now when I run the 
program as root, it works, but when I run it as a "normal" user, I get 
"not-found" errors (exact text included at bottom).  I've made sure the 
stty.* and Tty* files have had their permissions changed (same with Expect), 
so they can be read by all.

What am I not doing?  Is there another file I need to change the permissions 
on?  I would think so, since root has no problem running this program.

Thanks!

Hal

Text of error:

Can't locate loadable object code for module IO::Tty in @INC (@INC contains: 
/usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 
/usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 
/usr/lib/perl5/site_perl .) at 
/usr/lib/perl5/site_perl/5.6.1/i386-linux/IO/Tty.pm line 28.
Compilation failed in require at 
/usr/lib/perl5/site_perl/5.6.1/i386-linux/IO/Pty.pm line 7.
BEGIN failed--compilation aborted at 
/usr/lib/perl5/site_perl/5.6.1/i386-linux/IO/Pty.pm line 7.
Compilation failed in require at /usr/lib/perl5/site_perl/5.6.1/Expect.pm 
line 22.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/Expect.pm 
line 22.
Compilation failed in require at ./fetch.pl line 100
BEGIN failed--compilation aborted at ./fetch.pl line 100

(line 100 in ./fetch.pl is "use Expect;" and presented no problems on the old 
system)

RE: [Expectperl-discuss] Warnings with latest Expect and IO::Tty/Pty

[Chris R. D. <cdo...@dm...>]

I am using perl 5.6.1 on cygwin (1.3.10) and saw the same warnings.  The fix
also made them go away.

Thanks,
# Chris

______________________________________________________________________
Chris Donnelly                cdo...@dm...
Software Systems Architect
Digital Motorworks
Austin, TX                    (512) 692-1101


-----Original Message-----
From: exp...@li...
[mailto:exp...@li...]On Behalf Of
Stephen
Sent: Wednesday, March 27, 2002 4:29 AM
To: exp...@li...
Subject: Re: [Expectperl-discuss] Warnings with latest Expect and
IO::Tty/Pty


On Wed, 27 Mar 2002 RGi...@a1... wrote:

>> I am however getting a couple of warnings, not sure if they are
>> important or not but they are a little annoying. They are:
>
>I only used perl5.6.0, so this might be a peculiarity of 5.5.3.  Please
>try changing those lines to
>
>  eval { local $^W = 0; undef local $SIG{__DIE__}; require IO::Stty };
>
>and see if the warnings go away.

Yes, that got rid of the warnings. They were never a problem, just
a little annoying to see all the time.

Thanks,
	Stephen Quinney


-------- "They sought it with thimbles, they sought it with care; --------
            They pursued it with forks and hope;
          They threatened its life with a railway-share;
----------- They charmed it with smiles and soap." -----------------------


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

Re: [Expectperl-discuss] Warnings with latest Expect and IO::Tty/Pty

[Stephen <S.J...@du...>]

On Wed, 27 Mar 2002 RGi...@a1... wrote:

>> I am however getting a couple of warnings, not sure if they are
>> important or not but they are a little annoying. They are: 
>
>I only used perl5.6.0, so this might be a peculiarity of 5.5.3.  Please 
>try changing those lines to 
>
>  eval { local $^W = 0; undef local $SIG{__DIE__}; require IO::Stty };
>
>and see if the warnings go away.

Yes, that got rid of the warnings. They were never a problem, just
a little annoying to see all the time.

Thanks,
	Stephen Quinney


-------- "They sought it with thimbles, they sought it with care; --------
            They pursued it with forks and hope;
          They threatened its life with a railway-share;
----------- They charmed it with smiles and soap." -----------------------

Re: [Expectperl-discuss] Warnings with latest Expect and IO::Tty/Pty

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

> I am however getting a couple of warnings, not sure if they are
> important or not but they are a little annoying. They are: 
> 
> Use of uninitialized value at
> /loc/lepus/dph3sjq/perl/sun4-solaris/IO/Tty.pm line 19.
> 
> Use of uninitialized value at
> /loc/lepus/dph3sjq/perl/sun4-solaris/IO/Pty.pm line 16.
> 
> These refer to the lines in the two modules which both say:
> 
> eval { undef local $SIG{__DIE__}; local $^W = 0; require IO::Stty };
> 
> My perl version details are:
> 
> Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:

I only used perl5.6.0, so this might be a peculiarity of 5.5.3.  Please 
try changing those lines to 

  eval { local $^W = 0; undef local $SIG{__DIE__}; require IO::Stty };

and see if the warnings go away.

Hope this helps,

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

[Expectperl-discuss] Warnings with latest Expect and IO::Tty/Pty

[Stephen <S.J...@du...>]

I have just compiled and installed IO::Tty/Pty version 1.01 and Expect
1.15 on my Solaris 8 box, details here:

SunOS duss0 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-250

everything compiles, installs, passes the tests and runs which is great! 
Glad to see things working again after some difficulties i've had with the
recent earlier versions of IO::Tty/Pty. I am however getting a couple of
warnings, not sure if they are important or not but they are a little
annoying. They are: 

Use of uninitialized value at
/loc/lepus/dph3sjq/perl/sun4-solaris/IO/Tty.pm line 19.

Use of uninitialized value at
/loc/lepus/dph3sjq/perl/sun4-solaris/IO/Pty.pm line 16.

These refer to the lines in the two modules which both say:

eval { undef local $SIG{__DIE__}; local $^W = 0; require IO::Stty };

My perl version details are:

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=solaris, osvers=2.7, archname=sun4-solaris
    uname='sunos rlsul2 5.7 generic_106541-08 sun4u sparc sunw,ultra-5_10
'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O', gccversion=
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib'

Re: [Expectperl-discuss] Getting weird error while trying to Rlogin

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

> I have Expect 1.12 on my system(Solaris 7
> s998s_SunServer_21al2b).

Please upgrade to IO-Tty v1.01 and Expect v1.15.  Be sure to read the 
FAQs in the Expect docs.

> 2)The second query which I have is how do I handle ANY
> prompt when i rlogin into the server.I am actually
> taking username and password in a cgi-script and then
> spawning a rlogin-session.Since different users may
> have different values set for PS1,what is the most
> efficient regular expression to be put in 
> $rlogin->expect followed by which I will be able to
> send a command using $rlogin->send("cmd\r");

Sorry, there is no generic answer.  A user can change the prompt to 
something completely arbitrary.  qr(^\S*[]$#%>] \Z) should cover the 
most common styles, though.

I'd suggest switching to 'rsh' to avoid the prompt issue completely, or 
even better to use 'ssh'.

Hope this helps,

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

Re: [Expectperl-discuss] Getting weird error while trying to Rlogin

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

> On running this program,I get the following errors on
> the terminal.
> *****************************************************
> tcgetattr: Invalid argument
> ioctl TIOCGETP: Invalid argument
> ioctl TIOCLGET: Invalid argument
> ioctl TIOCGETC: Invalid argument
> ioctl TIOCGLTC: Invalid argument
> ioctl TIOCGETP: Invalid argument
> ioctl TIOCLGET: Invalid argument
> ioctl TIOCSLTC: Invalid argument
> ioctl TIOCSETC: Invalid argument
> ioctl TIOCSETN 3: Invalid argument
> ioctl TIOCLSET: Invalid argument
> Password:
> 
> Followed by this,it logs in to the $HOST machine.

Strange, seems like rlogin has problems with the terminal.  Which version
of IO-Tty are you running?

> But gives this error at the prompt.
> 
> *****************************************************
> [[24;80Rresize: Time out occurred
> ruchi@XYZ:/home/ruchi $

That are terminal codes you are seeing there.  The remote shell wants to query
the window size, but your application doesn't send the data, that's the reason for
the timeout.  Nothing to worry about.

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

[Expectperl-discuss] Getting weird error while trying to Rlogin

[ruchi g. <ru...@ya...>]

Hi,
I have written a small Expect script in a cgi script.


$rlogin=Expect->spawn("rlogin -l $USER $HOST") or die
"spawn failed";
$rlogin->expect(30,"ssword: ") || die "Never got
password prompt on $HOST, ".$rlogin->exp_error()."\n";
print $rlogin "$pass\r";
$rlogin->expect(30,"id\r\n");
$rlogin->hard_close();

On running this program,I get the following errors on
the terminal.
*****************************************************
tcgetattr: Invalid argument
ioctl TIOCGETP: Invalid argument
ioctl TIOCLGET: Invalid argument
ioctl TIOCGETC: Invalid argument
ioctl TIOCGLTC: Invalid argument
ioctl TIOCGETP: Invalid argument
ioctl TIOCLGET: Invalid argument
ioctl TIOCSLTC: Invalid argument
ioctl TIOCSETC: Invalid argument
ioctl TIOCSETN 3: Invalid argument
ioctl TIOCLSET: Invalid argument
Password: 

Followed by this,it logs in to the $HOST machine.
But gives this error at the prompt.

*****************************************************
[[24;80Rresize: Time out occurred
ruchi@XYZ:/home/ruchi $


Cheers,
R.



__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

Re: [Expectperl-discuss] No match,

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

RGi...@a1... writes:
[eravin wrote]
> > 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?

It should be, but there's the pathological case where
there's the accidental match exists *AND* that pattern happens to show
up at the end of a packet *AND* there's a delay before the next
packet.  In which case, the pattern would be at the end of the
accumulator and expect() would be fooled.  Not a very likely case,
but it could still happen (and most certainly WILL happen if I
used \Z that way, probably three times a day :-).

But thanks for the reminder about \Z, I had forgotten about it.

	-- Ed

Re: [Expectperl-discuss] several sequental spawns

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

=F7 =F7=D4=D2, 19.03.2002, =D7 15:56, RGi...@a1... =CE=C1=D0=C9=D3=C1=CC=
:
> Don't forget that an Expect object is basically a filehandle, and the=20
> semantics of cloning a filehandle are vague, to say the least.  Should=20
> the filehandle be connected to the same file/process?  Should we reuse=20
> the pty?  Copy the tty settings?  Or just the Expect-specific=20
> parameters?  I don't see a clear, easy DWIM-solution for this, so I=20
> wouldn't poke deeper into this snake-pit...
Ok, I see, probably 'clone' is a bad idea... I just didn't count all
possible problems in design and implementation before asking for it...

> But what I could add is a check that prohibits spawning another process=20
> with an already-used object to avoid such misunderstandings.  And of=20
> course amend the docs...
Ok, it would be enough for a newbie like me :-)

Thank you.

Alexey Morozov.

Re: [Expectperl-discuss] several sequental spawns

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

> > sounds reasonable. May be it's time to add a 'clone' function to 
> > Expect? All 'shareable' settings are to be copied inside the 
> > func, and unique ones get re-created... Unfortunately I know
> > too little about an Expect's object insides for the moment
> > and probably can't say exactly whether 'clone' should allocate
> > a new pty for each new instance etc... 
> 
> 	I think you would have to. So, the purpose of the clone would be
> to do something like spawn a process using the same parameters? I 
> guess I'm not seeing much benefit over setting the default
> parameters using packagevariables, e.g. $Expect::Exp_Internal.
> Maybe I don't understand the concept of 'clone' well enough.
> 	Also, how would it apply to filehandles expectified using 
> exp_init?

Don't forget that an Expect object is basically a filehandle, and the 
semantics of cloning a filehandle are vague, to say the least.  Should 
the filehandle be connected to the same file/process?  Should we reuse 
the pty?  Copy the tty settings?  Or just the Expect-specific 
parameters?  I don't see a clear, easy DWIM-solution for this, so I 
wouldn't poke deeper into this snake-pit...

But what I could add is a check that prohibits spawning another process 
with an already-used object to avoid such misunderstandings.  And of 
course amend the docs...

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

[Expectperl-discuss] Expect FAQ (was Re: 'Ftp' acts different in Cygwin and Linux)

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

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

I see you haven't taken a look at the Expect docs v1.14 yet... :-)

OK, general call to all hands:  please take a look at the latest 
version, esp. the FAQ section that I merged into the main docs.  Any 
opinions, suggestions, criticism (witty and constructive) are 
appreciated.

Thanks!

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

Re: [Expectperl-discuss] several sequental spawns

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

> > 	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());
> >   ...
> > }
> sounds reasonable. May be it's time to add a 'clone' function to Expect?
> All 'shareable' settings are to be copied inside the func, and unique
> ones get re-created... Unfortunately I know too little about an Expect's
> object insides for the moment and probably can't say exactly whether
> 'clone' should allocate a new pty for each new instance etc...
> 

	I think you would have to. So, the purpose of the clone would be
to do something like spawn a process using the same parameters? I guess I'm
not seeing much benefit over setting the default parameters using package
variables, e.g. $Expect::Exp_Internal. Maybe I don't understand the concept
of 'clone' well enough.
	Also, how would it apply to filehandles expectified using 
exp_init?

> > 	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(?).
> Hmm, looks like I just repeated your words before reading entire message
> :-)...
> 
	Maybe, but you use new and interesting vocabulary. :-)

> Thank you and Roland a lot (but I can't see his mail in my box yet :-(
> ).

	Mostly Roland. He's been doing all the work lately :)

	Austin

Re: [Expectperl-discuss] several sequental spawns

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

=F7 =F0=CE=C4, 18.03.2002, =D7 21:18, Austin Schutz =CE=C1=D0=C9=D3=C1=CC:
> 	You would be able to do something like:
> $new_expect =3D Expect->new();
> %{ *$new_expect } =3D %{ *$old_expect };
Looks like an ugly hack probably leading to memory leaks and
unpredictable behaviour :-). My C++'ish past protests against things
like this :-)

> 	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) =3D @_;
>   $new->exp_internal($old->exp_internal());
>   ...
> }
sounds reasonable. May be it's time to add a 'clone' function to Expect?
All 'shareable' settings are to be copied inside the func, and unique
ones get re-created... Unfortunately I know too little about an Expect's
object insides for the moment and probably can't say exactly whether
'clone' should allocate a new pty for each new instance etc...

> 	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(?).
Hmm, looks like I just repeated your words before reading entire message
:-)...

Thank you and Roland a lot (but I can't see his mail in my box yet :-(
).

Alexey Morozov