Menu
▾
▴
expectperl-discuss
|
From: Sayre S. <sa...@qu...> - 2003-08-04 21:19:37
|
I am new to Expect. I am using it to control some serial devices that our company manufactures. They are connected on /dev/tty ports directly as RS232 devices. I open the port using IO::File and then connect that handle to Expect. I have a problem where Expect.pm occasionally closes the filehandle on the port giving the following message from the debug output: Waiting for new data (6 seconds)... handle id(3): new data. handle id(3): EOF handle id(3): closing... Returning from expect with TIMEOUT or EOF I have patched my problem by commenting out the $exp->hard_close(); on line 853 of Expect.pm - which I realize is a drastic step. What am I doing wrong? Why would expect decide to close my filehandle? What can I do about it so that I do not have to modify the Expect.pm program. Any help would be greatly appreciated. Thank you very much, Sayre Swarztrauber |
|
From: Austin S. <te...@of...> - 2003-08-04 22:06:28
|
On Mon, Aug 04, 2003 at 05:19:18PM -0400, Sayre Swarztrauber wrote:
> I am new to Expect. I am using it to control some serial devices that
> our company manufactures. They are connected on /dev/tty ports directly
> as RS232 devices. I open the port using IO::File and then connect that
> handle to Expect.
>
> I have a problem where Expect.pm occasionally closes the filehandle on
> the port giving the following message from the debug output:
>
> Waiting for new data (6 seconds)...
> handle id(3): new data.
> handle id(3): EOF
> handle id(3): closing...
> Returning from expect with TIMEOUT or EOF
>
>
> I have patched my problem by commenting out the
>
> $exp->hard_close();
>
> on line 853 of Expect.pm - which I realize is a drastic step.
>
> What am I doing wrong? Why would expect decide to close my filehandle?
> What can I do about it so that I do not have to modify the Expect.pm
> program.
I concur, this doesn't seem like something that should be done
during expect(). It should be up to the user to close the filehandle.
Also while checking this out I noticed:
# ugly hack for broken solaris ttys that spew <blank><backspace>
# into our pretty output
$buffer =~ s/ \cH//g;
should probably either be somewhere else or have a non-default flag for
turning it on. Users should be able to expect 8-bit clean data by default -
at least when the handle isn't a pty.
Austin
|
|
From: expect <ex...@ih...> - 2003-08-07 18:14:41
|
On Mon, 04 Aug 2003 17:19:18 -0400 Sayre Swarztrauber <sa...@qu...> wrote: > I am new to Expect. I am using it to control some serial devices that > our company manufactures. They are connected on /dev/tty ports directly > as RS232 devices. I open the port using IO::File and then connect that > handle to Expect. > > I have a problem where Expect.pm occasionally closes the filehandle on > the port giving the following message from the debug output: > > Waiting for new data (6 seconds)... > handle id(3): new data. > handle id(3): EOF > handle id(3): closing... > Returning from expect with TIMEOUT or EOF > > > I have patched my problem by commenting out the > > $exp->hard_close(); > > on line 853 of Expect.pm - which I realize is a drastic step. > > What am I doing wrong? Why would expect decide to close my filehandle? > What can I do about it so that I do not have to modify the Expect.pm > program. > > Any help would be greatly appreciated. This sounds familiar to me...something about been there and done that. Of course this may not be your problem. I simply didn't understand that to cause Expect to wait forever on a pattern match the perl 'undef' function has to be used in place of a $timeout value. What I did was just not define it and it didn't do what I Expect'd. my $proghandle = new Expect; $proghandle = Expect->spawn($myprog); $proghandle->expect(undef, $whatiamexpecting); It may make sense to modify the docs slightly to point out that the perl function undef should be specified. perldoc Expect "Simple interface: Given $timeout in seconds Expect will wait for $object's handle to produce one of the match_patterns. Due to o/s limitations $timeout should be a round number. If $timeout is 0 Expect will check one time to see if $object's handle contains any of the match_patterns. If $timeout is undef Expect will wait forever for a pattern to match." |
|
From: Roland G. <RGi...@cp...> - 2003-08-27 07:23:23
|
sorry for the belated reply... expect wrote: > On Mon, 04 Aug 2003 17:19:18 -0400 > Sayre Swarztrauber <sa...@qu...> wrote: > > >>I am new to Expect. I am using it to control some serial devices that >>our company manufactures. They are connected on /dev/tty ports directly >>as RS232 devices. I open the port using IO::File and then connect that >>handle to Expect. >> >>I have a problem where Expect.pm occasionally closes the filehandle on >>the port giving the following message from the debug output: >> >>Waiting for new data (6 seconds)... >>handle id(3): new data. >>handle id(3): EOF >>handle id(3): closing... >>Returning from expect with TIMEOUT or EOF >> >> >>I have patched my problem by commenting out the >> >> $exp->hard_close(); >> >>on line 853 of Expect.pm - which I realize is a drastic step. >> >>What am I doing wrong? Why would expect decide to close my filehandle? >>What can I do about it so that I do not have to modify the Expect.pm >>program. this works as intended, the other side (spwaned program) has closed its stdout, which normally is an indication that the program exits. if you need a more fine-grained control over the input and output streams, take a look at IPC::Run. >> >>Any help would be greatly appreciated. > > > > This sounds familiar to me...something about been there and done that. > Of course this may not be your problem. > > I simply didn't understand that to cause Expect to wait forever on > a pattern match the perl 'undef' function has to be used in place of > a $timeout value. What I did was just not define it and it didn't do > what I Expect'd. > > my $proghandle = new Expect; > $proghandle = Expect->spawn($myprog); > $proghandle->expect(undef, $whatiamexpecting); > > > It may make sense to modify the docs slightly to point out that the > perl function undef should be specified. > > > perldoc Expect > > "Simple interface: > > Given $timeout in seconds Expect will wait for $object's handle to > produce one of the match_patterns. Due to o/s limitations $timeout > should be a round number. If $timeout is 0 Expect will check one > time to see if $object's handle contains any of the match_patterns. > If $timeout is undef Expect will wait forever for a pattern to > match." > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Expectperl-discuss mailing list > Exp...@li... > https://lists.sourceforge.net/lists/listinfo/expectperl-discuss > |
|
From: Austin S. <te...@of...> - 2003-08-27 08:08:38
|
On Wed, Aug 27, 2003 at 09:22:45AM +0200, Roland Giersig wrote: > >>I have patched my problem by commenting out the > >> > >> $exp->hard_close(); > >> > >>on line 853 of Expect.pm - which I realize is a drastic step. > >> > >>What am I doing wrong? Why would expect decide to close my filehandle? > >>What can I do about it so that I do not have to modify the Expect.pm > >>program. > > this works as intended, the other side (spwaned program) has closed its > stdout, which normally is an indication that the program exits. if you > need a more fine-grained control over the input and output streams, take > a look at IPC::Run. Yes, this is true, _normally_, and maybe it would be worthwhile to try a non-blocking waitpid, or even block a couple seconds and do that. hard_close() will explicitly _kill_ the process, however. That doesn't seem like intuitive behavior during an expect() call, imo. soft_close might be a good choice, except that it also will kill the process if it doesn't go away after the handle is closed. What it should do (and should have done, my fault) is merely close the handle and wait for a bit, returning an error if the process doesn't go away by itself. Again that's all just imo. Austin |
|
From: Sayre S. <sa...@qu...> - 2003-08-27 13:53:33
|
I eventually fixed the problem by tediously debugging with the perl debugger. I was using a serial port both for ascii communication (cooked stty) and binary protocol xfers (raw stty), switching back and forth between the modes. Sometimes when the binary xfer was over and I set the port stty back to cooked, the other side had not yet finished the xfer. If it sent a ^D the Expect.pm module would close the port. I tried to set stty eof to undef after setting stty to cooked, but it the Stty.pm would not take a non-numeric argument on the eof parm. I set eof to 0 and it works fine now, even if there is a communication error. I removed my patch from Expect.pm and am getting good results even under error conditions. Thank you, Sayre Swarztrauber Roland Giersig wrote: > sorry for the belated reply... > > expect wrote: > >> On Mon, 04 Aug 2003 17:19:18 -0400 >> Sayre Swarztrauber <sa...@qu...> wrote: >> >> >>> I am new to Expect. I am using it to control some serial devices >>> that our company manufactures. They are connected on /dev/tty ports >>> directly as RS232 devices. I open the port using IO::File and then >>> connect that handle to Expect. >>> >>> I have a problem where Expect.pm occasionally closes the filehandle >>> on the port giving the following message from the debug output: >>> >>> Waiting for new data (6 seconds)... >>> handle id(3): new data. >>> handle id(3): EOF >>> handle id(3): closing... >>> Returning from expect with TIMEOUT or EOF >>> >>> >>> I have patched my problem by commenting out the >>> $exp->hard_close(); >>> >>> on line 853 of Expect.pm - which I realize is a drastic step. >>> >>> What am I doing wrong? Why would expect decide to close my >>> filehandle? What can I do about it so that I do not have to modify >>> the Expect.pm program. >> > > this works as intended, the other side (spwaned program) has closed > its stdout, which normally is an indication that the program exits. if > you need a more fine-grained control over the input and output > streams, take a look at IPC::Run. > > >>> >>> Any help would be greatly appreciated. >> >> >> >> >> This sounds familiar to me...something about been there and done that. >> Of course this may not be your problem. >> >> I simply didn't understand that to cause Expect to wait forever on >> a pattern match the perl 'undef' function has to be used in place of >> a $timeout value. What I did was just not define it and it didn't do >> what I Expect'd. >> >> my $proghandle = new Expect; >> $proghandle = Expect->spawn($myprog); >> $proghandle->expect(undef, $whatiamexpecting); >> >> >> It may make sense to modify the docs slightly to point out that the >> perl function undef should be specified. >> >> >> perldoc Expect >> >> "Simple interface: >> >> Given $timeout in seconds Expect will wait for $object's handle to >> produce one of the match_patterns. Due to o/s limitations $timeout >> should be a round number. If $timeout is 0 Expect will check one >> time to see if $object's handle contains any of the match_patterns. >> If $timeout is undef Expect will wait forever for a pattern to >> match." >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET sites including >> Data Reports, E-commerce, Portals, and Forums are available now. >> Download today and enter to win an XBOX or Visual Studio .NET. >> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >> >> _______________________________________________ >> 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 |
×
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