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

[Expectperl-discuss] Common mistake in return statements

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

  I just got bit by this, and I figure other people will too.  (And I'm sure
I'll hit it again.)

  So, remember, if you do this:


sub expectstuff  # return 1 for success, 0 for failure
{
  my($exp) = @_;
  $exp->expect($timeout,
               [$regex1 => sub { ... }],
               [$regex2 => sub { ... }],
               [$regex3 =>  # if we get this, we know it didn't work
                           sub { return 0 }],);
  return 1;
}

then your "return 0" statement is useless.  It's in an anonymous subroutine,
and that subroutine will return 0, but your expectstuff routine will still
return 1.

  That seems obvious, but I came about this in a roundabout way, because
originally I had something like [$regex3 => sub { die "..." }], but I wanted
to change it so my program didn't die just for failing with one connection.

jdb

Re: [Expectperl-discuss] EXPECT 1.15 on SOlaris 2.6 and Tru64 4.0D, E

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

> I am currently testing this module and have come across 3 failures
> that are
> common on the 3 OS'es. Has anyone seen this or has a fixe for it?

Could it be that the machines you are running the tests on are very 
busy?  But that would also mean that other tests would fail.  This 
behaviour is really reproducible?  It's always the same tests that fail 
consistently across all three OSes?  Are you running the same Perl 
version on all three machines?

I'm baffled...

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

Re: [Expectperl-discuss] IO-Tty on Alpha

[Roland G. <Ro...@Gi...>]

> I'm trying to build the IO::Tty Perl module (version 1.02) on an
> Alpha machine (OSF1 v4.0) and am hitting some problems. This may
> be due to the version of Perl that is installed

It is. 5.004_01 has been around a loong time (5 years). I once made 
sure that IO::Tty also builds and links under 5.004, but I must have 
made non-backward-compatible changes since then (the IO::Tty::Constant 
module creation is rather recent).  Sorry about that, but the way to go 
here is to upgrade to 5.6.1, as 5.004_01 isn't even the latest stable 
of that bunch (5.004_05 is).

Hope this helps,

Roland
--
Ro...@Gi...

[Expectperl-discuss] EXPECT 1.15 on SOlaris 2.6 and Tru64 4.0D, E

[Noel P. <noe...@mi...>]

Hi All,

I am currently testing this module and have come across 3 failures that are
common on the 3 OS'es. Has anyone seen this or has a fixe for it?

Thanks in advance.

...
ok 14
ok 15
not ok 16
# Test failed at test.pl line 86.

{
  my $exp = new Expect($Perl . q{ -e 'print "Begin\n"; sleep (5); print
"End\n";' });
  my $cnt = 0;
  $exp->expect(1,
               [ "Begin" => sub { ok(1); exp_continue; } ],
               [ "End" => sub { ok(1); } ],
               [ eof => sub { print "EOF\n"; ok(0); } ],
               [ timeout => sub { $cnt++; ($cnt < 7)? exp_continue : 0;} ],
              );
  ok($cnt > 2 and $cnt < 7);
  $exp->hard_close();
}

some string
ok 17
not ok 18
# Test failed at test.pl line 95.

{
  # timeout shouldn't destroy accum contents
  my $exp = new Expect($Perl . q{ -e 'print "some string\n"; sleep (5);' });
  ok(not defined $exp->expect(1, "NoMaTcH"));
  my $i = $exp->expect(1, '-re', 'some\s');
  ok (defined $i and $i == 1);
  $exp->hard_close();
}

Testing -notransfer...

X some other
ok 19
ok 20
ok 21
ok 22
ok 23
EOF
ok 24

Testing raw reversing...

isatty($exp): YES

   print "isatty(\$exp): ";
  if (POSIX::isatty($exp)) {
    print "YES\n";
  } else {
    print "NO\n";
  }

  $exp->raw_pty(1);

  $exp->spawn("$Perl -ne 'chomp; sleep 0; print scalar reverse, \"\\n\"'")
<------ goes to sleep here
    or die "Cannot spawn $Perl: $!\n";

*** Exit 130
Stop.

Noel Paul
Lead Unix Administrator
Mincom
Phone: 61-7-3364 9876
Fax     : 61-7-3364 9777
Email : Noe...@mi...
Http   : www.mincom.com

Mincom. The People. The Experience. The Vision.

This transmission is for the intended addressee only and is confidential
information. If you have received this transmission in error, please delete
it and notify the sender. The contents of this E-mail are the opinion of the
writer only and are not endorsed by the Mincom Group of companies unless
expressly stated otherwise.

[Expectperl-discuss] IO-Tty on Alpha

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

HI there,

I'm trying to build the IO::Tty Perl module (version 1.02) on an Alpha
machine (OSF1 v4.0) and am hitting some problems. This may be due to the
version of Perl that is installed (which i don't have direct control over)
but i'm not sure so if anyone can point me in the right direction i would
be very grateful. It does the perl Makefile.PL and make stages fine but
fails on make test and does not work when i try to 'use' it. The error
message i get from make test is:

PERL_DL_NONLAZY=1 /usr/local/bin/perl -I./blib/arch -I./blib/lib
-I/freeware/lib/perl5/alpha-dec_osf/5.00401 -I/freeware/lib/perl5 test.pl
1..4
Using /usr/users/nfp/nfp/tmp/IO-Tty-1.02/blib
Can't locate object method "export_to_level" via package
"IO::Tty::Constant" at
/usr/users/nfp/nfp/tmp/IO-Tty-1.02/blib/lib/IO/Tty.pm line 37.
BEGIN failed--compilation aborted at
/usr/users/nfp/nfp/tmp/IO-Tty-1.02/blib/lib/IO/Pty.pm line 7.
BEGIN failed--compilation aborted at test.pl line 19.
*** Exit 2
Stop.

Any enlightenment gratefully received, 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] unExpected problems

[Simon T. <si...@un...>]

Hello Michael,

> I have compiled in Expect  and dependent modules into perl,
> but can't get even the simplest example script to run.
> We are running perl on HP-UX10 on a HP-N1000 system.
> When I debug it I get the following error:
>
> spawn(/opt/perl5/lib/site_perl/5.005/Expect.pm:110):
> 110:      unless (defined ($pid)) {
>   DB<1> Expect::spawn(/opt/perl5/lib/site_perl/5.005/Expect.pm:110):
> 110:      unless (defined ($pid)) {
> ######### Forked, but do not know how to change a TTY. #########

Very odd. I have used Expect.pm in HP-UX 10.20 on one clients' site with no 
problems.

I know that pty allocation is a bit of a black art, so maybe you are running 
into something specific to your environment.

Have you tried:

  * Running the same test script as the root user (assuming that this is
    possible for you). This once helped narrow down a similar pty issue for me 
    in FreeBSD, where, for some reason, I could not allocate pty's unless I
    was the super-user. 

  * Using the tcl expect tool to debug, ie: if you happen to have the "expect"
    program installed on your machine, you can just type "expect" and when
    it gives you a prompt, enter "spawn sh". If pty allocation is OK on your
    machine, then this test should return a process id. Then at least you 
    would know that the problem was with your Expect.pm implementation.

  * Try a *really* simple test in perl, such as:

    perl -MExpect -e '$e = Expect->spawn("sh") ; print $e->pid()'

    On my system, this returns a PID.

Good luck.

Regards,

Simon Taylor
-- 
Unisolve Pty Ltd - Melbourne, Australia
+61 3 9568 2005

[Expectperl-discuss] unExpected problems

[<mos...@po...>]

Greetings,
I have compiled in Expect  and dependent modules into perl,
but can't get even the simplest example script to run.
We are running perl on HP-UX10 on a HP-N1000 system.
When I debug it I get the following error:

spawn(/opt/perl5/lib/site_perl/5.005/Expect.pm:110):
110:      unless (defined ($pid)) {
  DB<1> Expect::spawn(/opt/perl5/lib/site_perl/5.005/Expect.pm:110):
110:      unless (defined ($pid)) {
######### Forked, but do not know how to change a TTY. #########
  Define $DB::fork_TTY
       - or a function DB::get_fork_TTY() which will set $DB::fork_TTY.
  The value of $DB::fork_TTY should be the name of TTY to use.
  On UNIX-like systems one can get the name of a TTY for the given window
  by typing tty, and disconnect the shell from TTY by sleep 1000000.

Then perl hangs on the following line:
$self->make_slave_controlling_terminal();

Does anyone out there have any ideas?
Kind regards,
Michael Osborne
Queensland Medical Laboratory
Information Technology Officer

These opinions are my own and may not represent those of my employers.


This message was sent through MyMail http://www.mymail.com.au

[Expectperl-discuss] Expect problems

[<mic...@qm...>]

Greetings,
I have compiled in Expect  and dependent modules into perl,
but can't get even the simplest example script to run.
We are running perl on HP-UX10 on a HP-N1000 system.
When I debug it I get the following error:

spawn(/opt/perl5/lib/site_perl/5.005/Expect.pm:110):
110:      unless (defined ($pid)) {
  DB<1> Expect::spawn(/opt/perl5/lib/site_perl/5.005/Expect.pm:110):
110:      unless (defined ($pid)) {
######### Forked, but do not know how to change a TTY. #########
  Define $DB::fork_TTY
       - or a function DB::get_fork_TTY() which will set $DB::fork_TTY.
  The value of $DB::fork_TTY should be the name of TTY to use.
  On UNIX-like systems one can get the name of a TTY for the given window
  by typing tty, and disconnect the shell from TTY by sleep 1000000.

Then perl hangs on the following line:
$self->make_slave_controlling_terminal();

Does anyone out there have any ideas?
Kind regards,
Michael Osborne
Queensland Medical Laboratory
Information Technology Officer

These opinions are my own and may not represent those of my employers.

Re: [Expectperl-discuss] Windows interaction

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

On Thu, Jun 20, 2002 at 10:46:54AM +0200, Roland Giersig wrote:
> > On Wed, Jun 19, 2002 at 02:34:49PM -0700, Wim Verhaert wrote:
> > > Thanks for the replies,...
> > > It seems that the problem I have is related to the folowing command
> > > 
> > > print $session "$argument\n";
> > > 
> > > The problem now in the windows environement is the '\n'. When I 
> replace this
> > > with '\r' it works.
> > > I never had this problem in a unix environement. Any comments?
> > > 
> > 
> > 	This is an excellent question. I have had trouble with 
> different
> > unix applications expecting \r, so it's not windows specific.
> 
> Actually, "\r" is the correct thing to do to emulate the user pressing 
> the <return> key.

	Ahh, this makes sense. Another good FAQ candidate IMO.

	Austin

RE: [Expectperl-discuss] Windows interaction

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

> > 	This is an excellent question. I have had trouble with 
> different
> > unix applications expecting \r, so it's not windows specific.
> 
> Actually, "\r" is the correct thing to do to emulate the user 
> pressing 
> the <return> key.  This will usually get translated to "\n" 
> in the pty 
> according to terminal settings, but this is of course 
> system-specific. 

  I learned to use "\r" from the (TCL) Expect book, so it might provide even
more information for the curious.  We write our UNIX programs based on '\n'
but it is the terminal that translates our return key (control-M or '\r')
into the '\n'.  The terminal is a UNIX thing, so who can fathom what Windows
might do? :)  Because of the Expect book, I always use "\r".  Except when I
forget (which can lead to interesting results).

jdb

Re: [Expectperl-discuss] Windows interaction

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

> On Wed, Jun 19, 2002 at 02:34:49PM -0700, Wim Verhaert wrote:
> > Thanks for the replies,...
> > It seems that the problem I have is related to the folowing command
> > 
> > print $session "$argument\n";
> > 
> > The problem now in the windows environement is the '\n'. When I 
replace this
> > with '\r' it works.
> > I never had this problem in a unix environement. Any comments?
> > 
> 
> 	This is an excellent question. I have had trouble with 
different
> unix applications expecting \r, so it's not windows specific.

Actually, "\r" is the correct thing to do to emulate the user pressing 
the <return> key.  This will usually get translated to "\n" in the pty 
according to terminal settings, but this is of course system-specific. 

Please note the different semantics: you are emulating a user at a 
keyboard, you are not driving the application via a pipe.

> 	Short answer: do whatever works.

Right. :-)

Hope this helps,

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

Re: [Expectperl-discuss] Windows interaction

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

On Wed, Jun 19, 2002 at 02:34:49PM -0700, Wim Verhaert wrote:
> Thanks for the replies,...
> It seems that the problem I have is related to the folowing command
> 
> print $session "$argument\n";
> 
> The problem now in the windows environement is the '\n'. When I replace this
> with '\r' it works.
> I never had this problem in a unix environement. Any comments?
> 

	This is an excellent question. I have had trouble with different
unix applications expecting \r, so it's not windows specific.
	I suspect preference for \r vs \n is application specific, though
there are terminal parameters to specify whether \n gets translated to \r
or vice-versa. Then, a beauty of arcane history, when it gets echoed back
to you it is again filtered by the tty output settings (which is also
configurable via stty or IO::Stty, etc).
	I don't have any good answer for why an application would prefer one
vs. the other. Probably also arcane historical reasons. Most apps seem to
like \n. IIRC when I used cu to talk to modems they liked \r.

	Short answer: do whatever works.

	Austin

Re: [Expectperl-discuss] Windows interaction

[Wim V. <wve...@re...>]

Thanks for the replies,...
It seems that the problem I have is related to the folowing command

print $session "$argument\n";

The problem now in the windows environement is the '\n'. When I replace this
with '\r' it works.
I never had this problem in a unix environement. Any comments?

Thanks
Wim



----- Original Message -----
From: "Roland Giersig" <RGi...@CP...>
To: "Wim Verhaert" <wve...@re...>
Cc: <exp...@li...>
Sent: Tuesday, June 18, 2002 11:48 PM
Subject: Re: [Expectperl-discuss] Windows interaction


> > Wim Verhaert wrote:
> >
> > I am trying to use the expect module to interact with a windows 2000
system via telnet.
>
> Have you taken a look at the Net::Telnet module?  Any specific reasons to
not use it?
> Oh, BTW, you should be able to use Net::Telnet together with Expect by
initializing the
> Expect object with the Net::telnet filehandle (but I haven't tried this,
so feedback is
> appreciated...).
>
> Hope this helps,
>
> Roland
>

Re: [Expectperl-discuss] Windows interaction

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

> Wim Verhaert wrote:
> 
> I am trying to use the expect module to interact with a windows 2000 system via telnet.

Have you taken a look at the Net::Telnet module?  Any specific reasons to not use it? 
Oh, BTW, you should be able to use Net::Telnet together with Expect by initializing the 
Expect object with the Net::telnet filehandle (but I haven't tried this, so feedback is
appreciated...).

Hope this helps,

Roland

Re: [Expectperl-discuss] Windows interaction

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

On Tue, Jun 18, 2002 at 05:26:27PM -0700, Wim Verhaert wrote:
> I am trying to use the expect module to interact with a windows 2000 system via telnet.
> 
> The login is detected but when I need to enter the username it does not seem to continue (it seems as if the enter is not transmitted or understood).
> Does anyone ever used it to connect to a windows system? What am I missing here?
> 
> 
> Here is what I see: forgive my personal debugging.

	When in doubt use the debugging included with the module.

$Expect::Debug=1;
$Expect::Exp_Internal=1;

$telnet= Expect->spawn('telnet');

	etc.

	Austin

Re: [Expectperl-discuss] Windows interaction

[<ex...@ih...>]

Are you sure you're expecting the right string?
why does it print "looking for password or password"?



On Tue, 18 Jun 2002 17:26:27 -0700
"Wim Verhaert" <wve...@re...> wrote:

> I am trying to use the expect module to interact with a windows 2000 system via telnet.
> 
> The login is detected but when I need to enter the username it does not seem to continue (it seems as if the enter is not transmitted or understood).
> Does anyone ever used it to connect to a windows system? What am I missing here?
> 
> 
> Here is what I see: forgive my personal debugging.
> 
> ...........Looking for 'login or login' in TIME: '30' seconds
> Trying xxx.xxx.xxx.xxx...
> Connected to xxx.xxx.xxx.xxx.
> Escape character is '^]'.
> Microsoft (R) Windows (TM) Version 5.00 (Build 2195)
> Welcome to Microsoft Telnet Service
> Telnet Server Build 5.00.99201.1
> login:
> exp..............Found(login).
> ..............printing with argument administrator
> 
> exp...........Looking for 'password or password' in TIME: '30' seconds
> administrator
> 
> exp.............Did not find "password or password"...
> 
> 
> Thanks
> 
> Wim
> 
> 

Re: [Expectperl-discuss] Windows interaction

[Simon T. <si...@un...>]

On Wed, 19 Jun 2002 10:26, Wim Verhaert wrote:
> I am trying to use the expect module to interact with a windows 2000 system
> via telnet.
>
> The login is detected but when I need to enter the username it does not
> seem to continue (it seems as if the enter is not transmitted or
> understood). Does anyone ever used it to connect to a windows system? What
> am I missing here?

This should be straightforward enough, why don't you post the code fragment, 
and I'll see if I can run it here.

Regards,

Simon Taylor

-- 
Unisolve Pty Ltd - Melbourne, Australia
+61 3 9568 2005

[Expectperl-discuss] Windows interaction

[Wim V. <wve...@re...>]

I am trying to use the expect module to interact with a windows 2000 =
system via telnet.

The login is detected but when I need to enter the username it does not =
seem to continue (it seems as if the enter is not transmitted or =
understood).
Does anyone ever used it to connect to a windows system? What am I =
missing here?


Here is what I see: forgive my personal debugging.

...........Looking for 'login or login' in TIME: '30' seconds
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
Microsoft (R) Windows (TM) Version 5.00 (Build 2195)
Welcome to Microsoft Telnet Service
Telnet Server Build 5.00.99201.1
login:
exp..............Found(login).
..............printing with argument administrator

exp...........Looking for 'password or password' in TIME: '30' seconds
administrator

exp.............Did not find "password or password"...


Thanks

Wim

RE: [Expectperl-discuss] autoexpect in perl!

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

As I told Asher, porting the Tcl/Expect autoexpect script shouldn't be 
too hard and quite straightforward, only the select() loop has to be 
rewritten, as Perl/Expects interconnect() isn't powerful enough...

Roland

Quoting "Blackstone, J. David" <jda...@ci...>:
>   Oh, I wish.  It'll happen someday, just give it time.
> 
> jdb
> 
> > -----Original Message-----
> > From: Asher Diamond [mailto:as...@ve...]
> > Sent: Sunday, June 16, 2002 9:44 AM
> > To: exp...@li...
> > Subject: [Expectperl-discuss] autoexpect in perl!
> > 
> > 
> > Excited? So would I be. If it existed.
> > 
> > Would any of you like to give it a crack?
> > I repeat here a discussion I had with Roland, leader of this
> pack.
> > Roland, I appreciate your help, but it was still a little to
> > abstract for my current IO::Tty and Expect skills.
> > 
> > Asher
> > 
> > 
> 


-- 
RGi...@cp...

RE: [Expectperl-discuss] autoexpect in perl!

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

  Oh, I wish.  It'll happen someday, just give it time.

jdb

> -----Original Message-----
> From: Asher Diamond [mailto:as...@ve...]
> Sent: Sunday, June 16, 2002 9:44 AM
> To: exp...@li...
> Subject: [Expectperl-discuss] autoexpect in perl!
> 
> 
> Excited? So would I be. If it existed.
> 
> Would any of you like to give it a crack?
> I repeat here a discussion I had with Roland, leader of this pack.
> Roland, I appreciate your help, but it was still a little to
> abstract for my current IO::Tty and Expect skills.
> 
> Asher
> 
> 

[Expectperl-discuss] autoexpect in perl!

[Asher D. <as...@ve...>]

Excited? So would I be. If it existed.

Would any of you like to give it a crack?
I repeat here a discussion I had with Roland, leader of this pack.
Roland, I appreciate your help, but it was still a little to
abstract for my current IO::Tty and Expect skills.

Asher

Re: [Expectperl-discuss] Re: perl 500404 with Expect 1.15

[<ex...@ih...>]

On Mon, 10 Jun 2002 21:41:20 +0200
Roland Giersig <RGi...@CP...> wrote:

> > >> If only life were so simple....I have the power to perform the
> > >> upgrade but there are dependencies on this perl.  I don't know what
> > >> they are....
> > >
> > >   Oh, ho, ho. :)   You need my super-special means of running many
> > >   perls at once trick.  Compile with --prefix=/usr/local/perl561. 
> > >   Make symlinks from everything in /usr/local/perl561/bin EXCEPT
> > >   /usr/local/perl561/bin/perl into/usr/local/bin.  Then write your
> > >   programs explicitly with:#!/usr/local/bin/perl5.6.1
> > > or
> > > #!/usr/[local/]?bin/perl5.00502
> > >
> > >   Then your programs don't break on upgrades and you can easily
> > >   remove a version as a unit if and when you upgrade all programs
> > >   that used it.
> > 
> > I must be missing something obvious.... How will this co-exist
> > with the the current /usr/local/bin/perldoc etc.??
> 
> Well, it won't.  But as you won't be doing development under the old
> perl, you won't need its user dpcumentation, i.e. the old perldoc.  The
> same goes for perlbug and perlcc (probably).  So you can replace those
> three with the new version.  Alternatively you might consider changing
> all the #! lines in the old scripts to point at perl5.00404 instead of
> just perl.


For now the new scripts will point to the new perl, thanks
for the ideas. 





> 
> Hope this clears things up.
> 
> Roland

Re: [Expectperl-discuss] Re: perl 500404 with Expect 1.15

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

> >> If only life were so simple....I have the power to perform the upgrade
> >> but there are dependencies on this perl.  I don't know what
> >> they are....
> >
> >   Oh, ho, ho. :)   You need my super-special means of running many perls at
> > once trick.  Compile with --prefix=/usr/local/perl561.  Make symlinks from
> > everything in /usr/local/perl561/bin EXCEPT /usr/local/perl561/bin/perl into
> > /usr/local/bin.  Then write your programs explicitly with:
> > #!/usr/local/bin/perl5.6.1
> > or
> > #!/usr/[local/]?bin/perl5.00502
> >
> >   Then your programs don't break on upgrades and you can easily remove a
> > version as a unit if and when you upgrade all programs that used it.
> 
> I must be missing something obvious.... How will this co-exist
> with the the current /usr/local/bin/perldoc etc.??

Well, it won't.  But as you won't be doing development under the old perl,
you won't need its user dpcumentation, i.e. the old perldoc.  The same goes 
for perlbug and perlcc (probably).  So you can replace those three with the 
new version.  Alternatively you might consider changing all the #! lines in
the old scripts to point at perl5.00404 instead of just perl.

Hope this clears things up.

Roland

Re: [Expectperl-discuss] Suggestions for FAQ entries

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

> > > [Might need to reword this.  Suggestions?  See
> > > http://use.perl.org/~djberg96/journal/5430/]
> > > 
> > > Spawning a process just starts it up.  From then on, any 
> > interaction with
> > > your process, including waiting for it to end, is up to 
> > you.  Usually this
> > > involves expect()ing output.  If there is no output, 
> > however, you will need
> > > to expect() a special signal sent when the process ends called eof.
> > 
> > 	Maybe I'm missing something. Why do I _need_ to expect 
> > eof? Expect
> > should return at eof. It should also be setting $err.
> > 
> > $process->expect(undef);
> > if( $process->error() =~ /EOF/ ) {
> >   waitpid($process->pid());
> > }
> > 
>   Or you can do that.  Want to rewrite it to include the alternative? :)
> The way I showed is more like the original TCL Expect.  I'm happy to see
> Expect.pm makes Expect very Perl-like by following the TMTOWTDI rule. :)
> 

	I could. I guess there could be a little discussion of the different
ways to reap child processes. Another way to do it is just:

undef($process);

	which reaps the process as part of the Expect deconstructor.

	Are we submitting interesting things as patches to what's in
CVS?

	Austin

[Expectperl-discuss] Re: perl 500404 with Expect 1.15

[<ex...@ih...>]

Blackstone, J. David writes: 

>  
> 
>> -----Original Message-----
>> From: ex...@ih... [mailto:ex...@ih...]
>> Sent: Thursday, June 06, 2002 7:35 PM
>> To: Blackstone, J. David
>> Cc: exp...@li...
>> Subject: Re: perl 500404 with Expect 1.15
> 
> ... 
> 
>> It looks like my problems are in Expect with spawn
>> these lines seem to be where things just hang:  
>> 
>>   144      open(STDIN,"<&". $slv->fileno())
>>   147      open(STDOUT,">&". $slv->fileno())
>>   150      open(STDERR,">&". $slv->fileno())  
>> 
>> Okay maybe I'm SOL but maybe someone has a hunch on what
>> the problem is???
> 
>   I think that is fairly new syntax as well.  I was trying something like
> that recently in an unrelated program and had trouble making it work, but I
> don't remember if it was because it was an older perl. 
> 
>> >   5.004 is several years old; I'd hammer my sysadmin with 
>> this and beg them
>> > to upgrade. :) 
>> 
>> If only life were so simple....I have the power to perform the upgrade
>> but there are dependencies on this perl.  I don't know what 
>> they are.... 
> 
>   Oh, ho, ho. :)   You need my super-special means of running many perls at
> once trick.  Compile with --prefix=/usr/local/perl561.  Make symlinks from
> everything in /usr/local/perl561/bin EXCEPT /usr/local/perl561/bin/perl into
> /usr/local/bin.  Then write your programs explicitly with:
> #!/usr/local/bin/perl5.6.1
> or
> #!/usr/[local/]?bin/perl5.00502 
> 
>   Then your programs don't break on upgrades and you can easily remove a
> version as a unit if and when you upgrade all programs that used it.

I must be missing something obvious.... How will this co-exist
with the the current /usr/local/bin/perldoc etc.??