Re: [Expectperl-discuss] expect closing port handle

[Sayre S. <sa...@qu...>]

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