Menu
▾
▴
expectperl-discuss
|
From: <ex...@ih...> - 2002-07-21 00:52:00
|
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
|
|
From: <ex...@ih...> - 2002-07-21 19:13:06
|
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
>
|
|
From: R. H. <rhu...@ih...> - 2002-07-22 16:17:38
|
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
>
|
|
From: Roland G. <RGi...@cp...> - 2002-07-23 09:06:05
|
> 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...
|
|
From: <ex...@ih...> - 2002-07-23 15:14:40
|
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.
|
|
From: Stephen <S.J...@du...> - 2002-07-23 16:07:45
|
It seems to me that the only problem here is that you are using the key,
value pair system like a hash. When i want to do a regexp match i always
do something like:
$obj->expect(undef,'-re',$item);
this works for me. I'm not sure it's intended to work with the => is it?
Stephen
>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.
-------- "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." -----------------------
|
|
From: <ex...@ih...> - 2002-07-24 06:12:16
|
On Tue, 23 Jul 2002 17:01:51 +0100 (BST) Stephen <S.J...@du...> wrote: > It seems to me that the only problem here is that you are using the key, > value pair system like a hash. When i want to do a regexp match i always > do something like: > > $obj->expect(undef,'-re',$item); > > this works for me. I'm not sure it's intended to work with the => is it? Yes, I understood that idiom to be acceptable too, although as someone pointed out the quotes may introduce problems. > > Stephen > > >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. > > > -------- "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." ----------------------- > > > > > ------------------------------------------------------- > 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 > |
|
From: Austin S. <te...@of...> - 2002-07-24 06:00:50
|
On Tue, Jul 23, 2002 at 08:14:35AM -0700, ex...@ih... wrote: > 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? Dunno, what's $item? Also, why the double quotes in "$item"? It's certainly possible to make illegal regexps that will have unexpected behaviors. Also putting in double quotes may end up in an extra unexpected interpolation. > > 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. > That would definitely not be proper behavior. Austin |
|
From: <ex...@ih...> - 2002-07-24 06:08:24
|
On Tue, 23 Jul 2002 23:00:07 -0700 Austin Schutz <te...@of...> wrote: > On Tue, Jul 23, 2002 at 08:14:35AM -0700, ex...@ih... wrote: > > 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? > > Dunno, what's $item? Also, why the double quotes in "$item"? It's Actually I think I did at one point try $obj->expect(undef, '-re', $item); $item could be like: [yes] or [no] or [/home/efudd] etc., etc. > certainly possible to make illegal regexps that will have unexpected > behaviors. Also putting in double quotes may end up in an extra unexpected > interpolation. Perhaps that's the issue then, an illegal regexp in the form: [somealphastring] the brackets in this case could well be the problem. I'll investigate as soon as I can. > > > > > 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. > > > > That would definitely not be proper behavior. > > Austin > |
|
From: Austin S. <te...@of...> - 2002-07-24 07:08:36
|
> > $item could be like: [yes] or [no] or [/home/efudd] etc., etc. > ..and a regexp of /[yes]/ will match a letter that is not a y, e, or s (perldoc perlre). I found myself getting frustrated trying to track down bugs induced by strings which contained dots or question marks, which have special meaning in perl regexps - thus the default literal matching behavior of non-archaic versions of Expect. If you don't use '-re' you don't have to worry about regexp meanings of characters, and the behavior is more predictable. That said, if you really want to use a regexp, try setting $Expect::Exp_Internal=1 so you can see what/how the regexp is actually matching. Austin |
|
From: <ex...@ih...> - 2002-07-24 15:06:28
|
On Wed, 24 Jul 2002 00:08:02 -0700 Austin Schutz <te...@of...> wrote: > > > > $item could be like: [yes] or [no] or [/home/efudd] etc., etc. > > > > ..and a regexp of /[yes]/ will match a letter that is not a y, e, or s you mean "that is a y, e, or s", [^yes] is the anti-match > (perldoc perlre). I found myself getting frustrated trying to track down bugs > induced by strings which contained dots or question marks, which have special > meaning in perl regexps - thus the default literal matching behavior of > non-archaic versions of Expect. If you don't use '-re' you don't have to > worry about regexp meanings of characters, and the behavior is more > predictable. > That said, if you really want to use a regexp, try setting > $Expect::Exp_Internal=1 so you can see what/how the regexp is actually > matching. Whatever the case I still think it should wait forever trying to match. > > Austin > |
|
From: Austin S. <te...@of...> - 2002-07-24 16:42:16
|
On Wed, Jul 24, 2002 at 08:06:24AM -0700, ex...@ih... wrote: > On Wed, 24 Jul 2002 00:08:02 -0700 > Austin Schutz <te...@of...> wrote: > > > > > > > $item could be like: [yes] or [no] or [/home/efudd] etc., etc. > > > > > > > ..and a regexp of /[yes]/ will match a letter that is not a y, e, or s > > you mean "that is a y, e, or s", [^yes] is the anti-match > Argh! I hate those late night brain typos! Austin |
|
From: Roland G. <RGi...@cp...> - 2002-08-04 10:12:54
|
> Whatever the case I still think it should wait forever trying to > match. It probably did, it matched on the first 'y', 'e' OR 's' that came along. D'oh! Roland -- RGi...@cp... |
|
From: <ex...@ih...> - 2002-08-06 01:24:58
|
On Sun, 4 Aug 2002 12:12:11 +0200 Roland Giersig <RGi...@cp...> wrote: > > Whatever the case I still think it should wait forever trying to > > match. > > It probably did, it matched on the first 'y', 'e' OR 's' that came > along. D'oh! Umm no, read the original thread again. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X