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

Re: [Expectperl-discuss] Strange time out and hard close

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

On Tue, 23 Jul 2002 11:05:21 +0200
Roland Giersig <RGi...@cp...> wrote:

> > Ok, I know it's not healthy to talk to myself.... ;^)
> 
> Well, it's a start... :-)
> 
> > The problem seems to be some difference in how regex is handled.
> > 
> > If I just do $obj->expect(undef, $item);
> > everything works fine.
> > 
> > If I use instead $obj->expect(undef, -re => "$item");
> > Things fail mysteriously (to me anyway).  I'm certain that my
> > understanding
> > of this module is incomplete so it's possible that I'm missing the
> > distinction between these 2 idioms.
> 
> perldoc Expect:
> 
>   Changed from older versions is the regular expression
>   handling. By default now all strings passed to expect()
>   are treated as literals. To match a regular expression
>   pass '-re' as a parameter in front of the pattern you
>   want to match as a regexp.
> 
>   Example:
> 
>    $object->expect(15, 'match me exactly','-re','match\s+me\s+exactly');
> 
> Anything unclear with that?  Should the docs be worded differently?
> 
> > > > The spawned program is an sh script.  The timeout comes only after
> > > > a few seconds at one point when the script is doing work.
> > > > Why is it timing out?  Is something strange happening to
> > > > $end_time?
> > > > 
> > > > Here's the bit of code from Expect.pm that gets me
> > > > to this point:
> > > > 
> > > > 1329:    if (($end_time <= time()) && ${*$self}{exp_Debug}) {
> > > > 1330:      print STDERR "Timed out waiting for an EOF from
> > ${*$self}{exp_Pty_Handle}.\r\n";
> > > > 1331:    }
> > > > 
> > > > Can anyone provide any clues? 
> 
> Without you providing more code?  No.

Don't think we're on the same wavelength, I suspect that it's my fault for
not providing enough info. I do understand "-re", I do not understand why
"-re" fails and when I don't specify "-re" things are fine.

In my previous post I noted that I was seeing this which
I only saw when I used $obj->expect(undef, -re => "$item");
and this showed up
Use of uninitialized value in concatenation (.) or string at /usr/btools/perl/lib/site_perl/5.6.1/Expect.pm line 1388


If I use this I have no problems:
$obj->expect(undef, $item);


So what's different about the code path for those two that causes one to fail?

Essentially that's all the code there is, it waits for a string which is a "key"
value and provides the corresponding "value" value. It almost appears as if the 
-re idiom is not respecting the undef for the timeout value and therefore is
not waiting indefinitely.

Re: [Expectperl-discuss] Strange time out and hard close

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

> Ok, I know it's not healthy to talk to myself.... ;^)

Well, it's a start... :-)

> The problem seems to be some difference in how regex is handled.
> 
> If I just do $obj->expect(undef, $item);
> everything works fine.
> 
> If I use instead $obj->expect(undef, -re => "$item");
> Things fail mysteriously (to me anyway).  I'm certain that my
> understanding
> of this module is incomplete so it's possible that I'm missing the
> distinction between these 2 idioms.

perldoc Expect:

  Changed from older versions is the regular expression
  handling. By default now all strings passed to expect()
  are treated as literals. To match a regular expression
  pass '-re' as a parameter in front of the pattern you
  want to match as a regexp.

  Example:

   $object->expect(15, 'match me exactly','-re','match\s+me\s+exactly');

Anything unclear with that?  Should the docs be worded differently?

> > > The spawned program is an sh script.  The timeout comes only after
> > > a few seconds at one point when the script is doing work.
> > > Why is it timing out?  Is something strange happening to
> > > $end_time?
> > > 
> > > Here's the bit of code from Expect.pm that gets me
> > > to this point:
> > > 
> > > 1329:    if (($end_time <= time()) && ${*$self}{exp_Debug}) {
> > > 1330:      print STDERR "Timed out waiting for an EOF from
> ${*$self}{exp_Pty_Handle}.\r\n";
> > > 1331:    }
> > > 
> > > Can anyone provide any clues? 

Without you providing more code?  No.

Hope this helps,

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

Re: [Expectperl-discuss] Strange time out and hard close

[R. H. <rhu...@ih...>]

On Sun, 21 Jul 2002 12:12:53 -0700
ex...@ih... wrote:

> Ok the real problem seems to start with this error message.
> The time it occurs seems to be hidden by the fact that
> the hard_close has some timeouts.
> 
> Use of uninitialized value in concatenation (.) or string at /usr/btools/perl/lib/site_perl/5.6.1/Expect.pm line 1388
> 
> I still don't know what to make of this???
> The spawn seems to trigger this problem.


Ok, I know it's not healthy to talk to myself.... ;^)

The problem seems to be some difference in how regex is handled.

If I just do $obj->expect(undef, $item);
everything works fine.

If I use instead $obj->expect(undef, -re => "$item");
Things fail mysteriously (to me anyway).  I'm certain that my understanding
of this module is incomplete so it's possible that I'm missing the
distinction between these 2 idioms.


> 
> 
> 
> On Sat, 20 Jul 2002 17:51:51 -0700
> ex...@ih... wrote:
> 
> > The spawned program is an sh script.  The timeout comes only after
> > a few seconds at one point when the script is doing work.
> > Why is it timing out?  Is something strange happening to
> > $end_time?
> > 
> > Here's the bit of code from Expect.pm that gets me
> > to this point:
> > 
> > 1329:    if (($end_time <= time()) && ${*$self}{exp_Debug}) {
> > 1330:      print STDERR "Timed out waiting for an EOF from ${*$self}{exp_Pty_Handle}.\r\n";
> > 1331:    }
> > 
> > Can anyone provide any clues? 
> > 
> > Timed out waiting for an EOF from spawn id(7).
> > spawn id(7) closed.
> > Pid 17299 of spawn id(7) exited, Status: 0x01
> > Closing spawn id(7).
> >         Expect::hard_close('Expect=GLOB(0x39e25c)') called at /usr/perl/lib/site_perl/5.6.1/Expect.pm line 1577
> >         Expect::DESTROY('Expect=GLOB(0x39e25c)') called at /tmp/inst.pl line 0
> >         eval {...} called at /tmp/inst.pl line 0
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Expectperl-discuss mailing list
> > Exp...@li...
> > https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> > 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

Re: [Expectperl-discuss] Strange time out and hard close

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

Ok the real problem seems to start with this error message.
The time it occurs seems to be hidden by the fact that
the hard_close has some timeouts.

Use of uninitialized value in concatenation (.) or string at /usr/btools/perl/lib/site_perl/5.6.1/Expect.pm line 1388

I still don't know what to make of this???
The spawn seems to trigger this problem.



On Sat, 20 Jul 2002 17:51:51 -0700
ex...@ih... wrote:

> The spawned program is an sh script.  The timeout comes only after
> a few seconds at one point when the script is doing work.
> Why is it timing out?  Is something strange happening to
> $end_time?
> 
> Here's the bit of code from Expect.pm that gets me
> to this point:
> 
> 1329:    if (($end_time <= time()) && ${*$self}{exp_Debug}) {
> 1330:      print STDERR "Timed out waiting for an EOF from ${*$self}{exp_Pty_Handle}.\r\n";
> 1331:    }
> 
> Can anyone provide any clues? 
> 
> Timed out waiting for an EOF from spawn id(7).
> spawn id(7) closed.
> Pid 17299 of spawn id(7) exited, Status: 0x01
> Closing spawn id(7).
>         Expect::hard_close('Expect=GLOB(0x39e25c)') called at /usr/perl/lib/site_perl/5.6.1/Expect.pm line 1577
>         Expect::DESTROY('Expect=GLOB(0x39e25c)') called at /tmp/inst.pl line 0
>         eval {...} called at /tmp/inst.pl line 0
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

[Expectperl-discuss] Strange time out and hard close

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

The spawned program is an sh script.  The timeout comes only after
a few seconds at one point when the script is doing work.
Why is it timing out?  Is something strange happening to
$end_time?

Here's the bit of code from Expect.pm that gets me
to this point:

1329:    if (($end_time <= time()) && ${*$self}{exp_Debug}) {
1330:      print STDERR "Timed out waiting for an EOF from ${*$self}{exp_Pty_Handle}.\r\n";
1331:    }

Can anyone provide any clues? 

Timed out waiting for an EOF from spawn id(7).
spawn id(7) closed.
Pid 17299 of spawn id(7) exited, Status: 0x01
Closing spawn id(7).
        Expect::hard_close('Expect=GLOB(0x39e25c)') called at /usr/perl/lib/site_perl/5.6.1/Expect.pm line 1577
        Expect::DESTROY('Expect=GLOB(0x39e25c)') called at /tmp/inst.pl line 0
        eval {...} called at /tmp/inst.pl line 0

RE: [Expectperl-discuss] Expect.pm success with perl 5.8.0

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

> -----Original Message-----
> From: Austin Schutz [mailto:te...@of...]
> Sent: Friday, July 19, 2002 3:53 PM
> To: Blackstone, J. David
> Cc: exp...@li...
> Subject: Re: [Expectperl-discuss] Expect.pm success with perl 5.8.0
>
> 	Has anyone tried out the 5.8 threads? It was such a 
> disaster last I
> looked a year or two ago that I haven't bothered since.
> 
> 	Austin

  I've heard good things about them.  I had to do a lot of Java work for a
distributed systems class this spring, and it was painfully obvious that the
threading I was doing made the projects fun, easy, and possible, but that
Perl couldn't do that.  I'm looking forward to being able to do that kind of
thing now. :)

jdb

Re: [Expectperl-discuss] Expect.pm success with perl 5.8.0

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

On Fri, Jul 19, 2002 at 03:41:32PM -0500, Blackstone, J. David wrote:
>   Just for the record, I have successfully build and installed Expect and
> its prerequisites under the brand new perl version 5.8.0 on x86 Linux, and
> it seems to work fine.
> 
> jdb

	Has anyone tried out the 5.8 threads? It was such a disaster last I
looked a year or two ago that I haven't bothered since.

	Austin

[Expectperl-discuss] Expect.pm success with perl 5.8.0

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

  Just for the record, I have successfully build and installed Expect and
its prerequisites under the brand new perl version 5.8.0 on x86 Linux, and
it seems to work fine.

jdb

RE: [Expectperl-discuss] Executing perl/expect script in backgrou nd.

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

Quoting "Blackstone, J. David" <jda...@ci...>:
>   I couldn't seem to get Net::Telnet to work with Expect.  Any
> pointers?

What did you try?  I'd create a new Net::Telnet object and use Expect-
>exp_init() to get an Expect object connected to the telnet connection. 
Should work...

>   Alternatively, it has since occurred to me that just creating a
> socket (or IO::Socket) would probably work just as well and would
> also avoid spawning a process.

Yes, but then you would have to do the initial telnet handshake by 
hand, which is why Net::Telnet was written...

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

RE: [Expectperl-discuss] Executing perl/expect script in backgrou nd.

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

  I couldn't seem to get Net::Telnet to work with Expect.  Any pointers?

  Alternatively, it has since occurred to me that just creating a socket (or
IO::Socket) would probably work just as well and would also avoid spawning a
process.

jdb

> -----Original Message-----
> From: Roland Giersig [mailto:RGi...@cp...]
> Sent: Friday, July 19, 2002 4:56 AM
> To: Alexander Bourov
> Cc: exp...@li...
> Subject: Re: [Expectperl-discuss] Executing perl/expect script in
> background.
> 
> 
> Quoting Alexander Bourov <ab...@en...>:
> > I have a strange situation:
> > when I try to execute the perl/expect script ( which spawns the
> > telnet ) in a background mode, say   abc.pl &
> > it hung. The ps shows actually two procecces and i have to 
> use kil -9
> > to kill them. Any idea what might be happening?
> 
> Looks like somebody is trying to read from its controlling tty, 
> probably telnet.  Are you aware of the Net::Telnet package?  
> Switching 
> to that instead of spawning another process is much more 
> efficient and 
> simpler and thus may solve your problem.
> 
> Hope this helps,
> 
> Roland
> -- 
> RGi...@cp...
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

Re: [Expectperl-discuss] Executing perl/expect script in background.

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

Quoting Alexander Bourov <ab...@en...>:
> I have a strange situation:
> when I try to execute the perl/expect script ( which spawns the
> telnet ) in a background mode, say   abc.pl &
> it hung. The ps shows actually two procecces and i have to use kil -9
> to kill them. Any idea what might be happening?

Looks like somebody is trying to read from its controlling tty, 
probably telnet.  Are you aware of the Net::Telnet package?  Switching 
to that instead of spawning another process is much more efficient and 
simpler and thus may solve your problem.

Hope this helps,

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

[Expectperl-discuss] Executing perl/expect script in background.

[Alexander B. <ab...@en...>]

I have a strange situation:
when I try to execute the perl/expect script ( which spawns the telnet ) =
in a background mode, say   abc.pl &
it hung. The ps shows actually two procecces and i have to use kil -9 to =
kill them.
Any idea what might be happening?

Re: [Expectperl-discuss] problem with opening non-default pty on Solaris

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

> Solaris is configured with 48 pairs of pseudo-terminal by
> default (/dev/ptyp0 to /dev/ptyrf).  But on some of the
> machines I work with, they have been configured to provide
> over 120 pseudo-terminals, and the first 70 or so pairs are
> claimed by some daemon processes.

Interesting. Which version of Solaris? Normally, Solaris 
provides /dev/ptmx to allocate a new pty/tty pair, and IO-Tty uses it 
before it tries the BSD-style ptys...

> When my perl-expect script is run, it fails because it (or
> IO:Pty) attempts to open the first 48 pairs and finds that
> none of them are openable - in other words, it does not
> realize that there are more non-default pty's available
> in the system.

Are you sure? The latest version of IO-Tty tries all possible character 
combinations, so if a free pty exists, IO-Tty should find it.

You could add

  $IO::Tty::Debug = 1;

to your script, then IO-Tty will print out low-level information about 
what method of pty allocation it is trying.

Hope this helps,

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

Re: [Expectperl-discuss] Getting at what you matched

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

On Wed, Jul 10, 2002 at 11:14:47AM +0200, Roland Giersig wrote:
> >   Playing devil's advocate to myself, $1, $2, etc. are only readable
> > because
> > I'm familiar with them.  $exp->matchlist could be argued to be much
> > more readable.
> 
> Setting $1, $2, etc. is actually a good DWIM-idea, but does anybody has 
> an idea how to circumvent the read-only attribute?
> 

	A guru I spoke with says they are effectively untouchable. I also
was wondering why they didn't show up with '-re'. Turns out they go out
of scope _fast_ after the pattern match - as soon as the current code
block ends, even from e.g. within if(){ }.
	It may be possible from XS, but it would likely be ugly.

	Austin

[Expectperl-discuss] problem with opening non-default pty on Solaris

[<kw...@nw...>]

All,

I'm new to this group.  May be the problem I encounter is
a simple and well known one.  Any help is appreciated.

Solaris is configured with 48 pairs of pseudo-terminal by
default (/dev/ptyp0 to /dev/ptyrf).  But on some of the
machines I work with, they have been configured to provide
over 120 pseudo-terminals, and the first 70 or so pairs are
claimed by some daemon processes.

When my perl-expect script is run, it fails because it (or
IO:Pty) attempts to open the first 48 pairs and finds that
none of them are openable - in other words, it does not
realize that there are more non-default pty's available
in the system.

************************************************************
*                                                          *
*  My question is, therefore: Is there a tunable parameter *
*  that we can use to inform Expect or Pty to recognize    *
*  the other non-default pty's?                            *
*                                                          *
************************************************************

Help is appreciated very much.

Ideally, Expect or Pty should automatically look up some
config file (or even just look into /dev to see how many
pty?? terminals have been set up) to figure that out by
itself.

mk kwong

Re: [Expectperl-discuss] Cool feature: logging subroutine

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

Quoting "Blackstone, J. David" <jda...@ci...>:

>   I haven't read the FAQ in ages.  I decided to look through it again
> today

Good decision! Now if I could only get others to do the same...

>   You can log all your output to a file, as in
> $x->log_file($filename), but
> to be even more flexible, you can specify a subroutine reference to
> receive the output, as in $x->log_file(\&subroutine) .
> 
>   I get the feeling that this can be abused in many useful ways. :)

That's why I've put it there... ;-)  Further suggestions welcomed.

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

RE: [Expectperl-discuss] Getting at what you matched

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

>   Playing devil's advocate to myself, $1, $2, etc. are only readable
> because
> I'm familiar with them.  $exp->matchlist could be argued to be much
> more readable.

Setting $1, $2, etc. is actually a good DWIM-idea, but does anybody has 
an idea how to circumvent the read-only attribute?

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

Re: [Expectperl-discuss] stty settings

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

> I'm not completely confident that I understand how 
> 
> $obj->slave->stty() syntax works.
> 
> Can I do this: obj->slave->stty(qw('rows 45' 'columns 80');

No, IO::Stty isn't a complete stty replacement (though there are 
efforts in that direction).

From the Expect FAQs:

  I'm spawning a telnet/ssh session and then let the user
  interact with it.  But screen-oriented applications on the
  other side don't work properly.

    You have to set the terminal screen size for that.  Luckily,
    IO::Pty already has a method for that, so modify your code
    to look like this:

      my $exp = new Expect;
      $exp->slave->clone_winsize_from(\*STDIN);
      $exp->spawn("telnet somehost);

    Also, some applications need the TERM shell variable set so
    they know how to move the cursor across the screen.  When
    logging in, the remote shell sends a query (Ctrl-Z I think)
    and expects the terminal to answer with a string, e.g.
    'xterm'.  If you really want to go that way (be aware,
    madness lies at its end), you can handle that and send back
    the value in $ENV{TERM}.  This is only a hand-waving
    explanation, please figure out the details by yourself.

  I set the terminal size as explained above, but if I resize
  the window, the application does not notice this.

    You have to catch the signal WINCH ("window size changed"),
    change the terminal size and propagate the signal to the
    spawned application:

      my $exp = new Expect;
      $exp->slave->clone_winsize_from(\*STDIN);
      $exp->spawn("ssh somehost);
      $SIG{WINCH} = \&winch;
      sub winch {
        $exp->slave->clone_winsize_from(\*STDIN);
        kill WINCH => $exp->pid if $exp->pid;
        $SIG{WINCH} = \&winch;
      }

      $exp->interact();

Hope this helps,

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

[Expectperl-discuss] Cool feature: logging subroutine

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

  I haven't read the FAQ in ages.  I decided to look through it again today
and found this neat feature, which may have been there forever:

  You can log all your output to a file, as in $x->log_file($filename), but
to be even more flexible, you can specify a subroutine reference to receive
the output, as in $x->log_file(\&subroutine) .

  I get the feeling that this can be abused in many useful ways. :)

jdb

RE: [Expectperl-discuss] Getting at what you matched

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

  Playing devil's advocate to myself, $1, $2, etc. are only readable because
I'm familiar with them.  $exp->matchlist could be argued to be much more
readable.

jdb

> -----Original Message-----
> From: Blackstone, J. David [mailto:jda...@ci...]
> Sent: Friday, July 05, 2002 2:19 PM
> To: exp...@li...
> Subject: [Expectperl-discuss] Getting at what you matched
> 
> 
>   This:
> 
> $x->expect($t,
>            [qr/literal(\d+)literal/ =>
>             sub {print "The number is $1\n"}]);
> 
> doesn't do what I would expect.  $1, $2, etc. don't seem to 
> be set by the
> regex matching in _multi_expect.
> 
>   Compare this to TCL Expect:
> 
> expect -re "literal(\[0-9]+)literal" {
>   send "The number is $expect_out(1,string)\n"
> }
> 
> 
>   Of course, getting _multi_expect to preserve $1, $2, etc. 
> would probably
> be a nightmare.  It would be Real Swell, though.
> 
> jdb
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Bringing you mounds of caffeinated joy.
> http://thinkgeek.com/sf
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 

[Expectperl-discuss] Getting at what you matched

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

  This:

$x->expect($t,
           [qr/literal(\d+)literal/ =>
            sub {print "The number is $1\n"}]);

doesn't do what I would expect.  $1, $2, etc. don't seem to be set by the
regex matching in _multi_expect.

  Compare this to TCL Expect:

expect -re "literal(\[0-9]+)literal" {
  send "The number is $expect_out(1,string)\n"
}


  Of course, getting _multi_expect to preserve $1, $2, etc. would probably
be a nightmare.  It would be Real Swell, though.

jdb

[Expectperl-discuss] stty settings

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

I'm not completely confident that I understand how 

$obj->slave->stty() syntax works.

Can I do this: obj->slave->stty(qw('rows 45' 'columns 80');

I'm having trouble running some scripts.  They work fine interactively
but when I run them through a command server they fail and I think
it may have something to do with window sizes.

My expect runs a bourne shell script if I run my perl script
by hand it executes the sh script fine responding with the right
answer when needed via expect.  I have a command server (perl)
that accepts commands from remote hosts and runs them as a specified
user.  The same expect that worked when run on the command line
fails when run through the command server.  It's not clear to
me what is happening but I'm guessing that it's window sizes
and that the sh script responds differently depending on the
window size and that causes a different response/answer pair
then what I get when I run manually.

Is this all horribly vague? Or does it ring a bell for anyone?

[Expectperl-discuss] Using Net::Telnet with Expect

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

  I think Roland mentioned recently that rather than spawning a telnet
process you can use a Net::Telnet object.  Unfortunately I've deleted the
message and can't figure out how to search either of sourceforge's mailing
list archive systems.

  How well does using a Net::Telnet object work?  Is this to be preferred
over spawning a telnet process?  Who has tried this so far, and are you
using it on a regular basis?

  I'm about to try stumbling over it myself, so wish me luck. :)

jdb

RE: [Expectperl-discuss] Common mistake in return statements

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

  Interestingly enough, Simon Cozens' talk on optimizer.pm and optimize.pm
at YAPC 2002 mentioned hacking the opcode tree in such a way that you could
make a return DWIM here.

  That's probably a ways off, though.

jdb

> -----Original Message-----
> From: Roland Giersig [mailto:RGi...@cp...]
> Sent: Friday, June 28, 2002 6:05 AM
> To: Blackstone, J. David
> Cc: exp...@li...
> Subject: Re: [Expectperl-discuss] Common mistake in return statements
> 
> 
> >   I just got bit by this, and I figure other people will too.  (And
> > I'm sure I'll hit it again.)
> 
> I'll put it into the docs. Now if I only could get people to read 
> them... :-/
> 
> Roland
> -- 
> RGi...@cp...
> 

Re: [Expectperl-discuss] Common mistake in return statements

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

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

I'll put it into the docs. Now if I only could get people to read 
them... :-/

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