stdin - flushing buffer - this should be an easy one

Discussion in 'Perl Misc' started by tj, May 4, 2004.

  1. tj

    tj Guest

    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.

    --
    TJ
     
    tj, May 4, 2004
    #1
    1. Advertising

  2. 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.
     
    James Willmore, May 4, 2004
    #2
    1. Advertising

  3. In article <2cRlc.12$>,
    tj <> wrote:
    :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.]
    --
    100% of all human deaths occur within 100 miles of Earth.
     
    Walter Roberson, May 4, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric

    Flushing the Buffer in .Net

    Eric, Apr 25, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    641
  2. arnuld
    Replies:
    5
    Views:
    807
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=
    Mar 18, 2007
  3. Ethan Metsger

    Decorators and buffer flushing

    Ethan Metsger, Feb 28, 2008, in forum: Python
    Replies:
    0
    Views:
    287
    Ethan Metsger
    Feb 28, 2008
  4. Andyza

    Flushing servers buffer

    Andyza, Jul 6, 2005, in forum: ASP General
    Replies:
    3
    Views:
    138
    Andyza
    Jul 7, 2005
  5. Nigel

    Problems flushing my buffer! (perl)

    Nigel, Oct 3, 2008, in forum: Perl Misc
    Replies:
    14
    Views:
    243
    Jim Gibson
    Oct 7, 2008
Loading...

Share This Page