stdin - flushing buffer - this should be an easy one

[tj]

Hi,
I apologize if this is not the correct forum for my question. Please
redirect if necessary.

I have a perl program which is communicating with a modem. I am obtaining
response codes from the modem by defining <MODEM> (/dev/ttyS3).

Think of this program as a clone of minicom. When using minicom, I submit
an "AT" code, and I know exactly what response codes I get from the modem,
and the response is displayed on the terminal.

However, using the perl program, I have to fetch the contents of the buffer.

system "stty 19200 < $modem";
open MODEM, "+<$modem" or die "Can't open $modem: $!";
select MODEM;
$|=1;
select STDOUT;

print MODEM $strData."\r";
print "Echoline: ".<MODEM>;

In minicom, I expect the echoline to be "OK\n\r".

In perl, fetching the results of <MODEM> are not consistent. Sometimes I
need to fetch one or two more <MODEM> calls to empty the buffer before I
can proceed. I assume I am making a very basic mistake, in how I am
calling <MODEM>, flushing the buffer, etc. Its hard to make a smart
looping subroutine, when Im not expecting a value in subsequent calls
anyway. ??

print MODEM $strData."\r";
print "Echoline: ".<MODEM>; #may or may not really be empty yet
print "Echoline: ".<MODEM>; #may or may not really be empty yet
print "Echoline: ".<MODEM>; #is probably empty by now.

 

[James Willmore]

On Tue, 04 May 2004 18:22:54 +0000, tj wrote:

[ ... ]

I have a perl program which is communicating with a modem. I am
obtaining response codes from the modem by defining <MODEM>
(/dev/ttyS3).

[ ... ]

I know this doesn't address the issue directly, but have you considered
using the Device::Modem module
(http://search.cpan.org/~cosimo/Device-Modem-1.36/docs/Modem.pod) ?

I make this suggestion because it looks like someone else already went
through this pain ... so you don't have to ;-)

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Schizophrenia beats being alone.

 

[Walter Roberson]

:Think of this program as a clone of minicom.

: system "stty 19200 < $modem";
: open MODEM, "+<$modem" or die "Can't open $modem: $!";

You need to reverse those two lines. stty settings only hold as long
as some process has the device open, and are reset each time the
last process closes the device. Your perl script does not have the
device open at the time you stty the device, and "system" will start
a new process to execute the stty command in. That new process will
die when stty is finished doing its work, leaving no processes holding
the port open, so the OS will reset the parameters. If you do the perl
open first, then your perl script will still have the device open
when the stty command finishes its job, so the OS will leave the parameters
as set by stty.


: select MODEM;
: $|=1;

:In perl, fetching the results of <MODEM> are not consistent. Sometimes I
:need to fetch one or two more <MODEM> calls to empty the buffer before I
:can proceed. I assume I am making a very basic mistake, in how I am
:calling <MODEM>, flushing the buffer, etc.

You should use additional parameters to stty to tell the system
the circumstances under which it should consider the input line
to be complete and thus release it to your buffer when you <MODEM>.
What you are encountering is that the default parameters are likely
based upon either timeouts or else whatever was available in the
buffer at the time of the interrupt.

However -- if you are trying to do anything at all interactive,
in which you might not be getting a complete line of output back,
then you really need to do single-character I/O, and you should
probably be using sysread() and select(). For example, if you need
to be able to detect that the remote system has sent you a
login: prompt and is sitting waiting for your username, then
you can't reliably handle that situation by reading a line at a time.


As another poster pointed out: people have already put a lot of this
functionality into modules available via CPAN, and it doesn't pay
to reimpliment it [not unless you know UNIX I/O at least as well
as the module author did.]