Kermit Script Output Out of Order - Protocols

This is a discussion on Kermit Script Output Out of Order - Protocols ; Hopefully this group is still monitored... I have been developing a kermit script. I have found that when a run the script normally from a linux prompt that the output is mostly in order. But if I fork a process ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Kermit Script Output Out of Order

  1. Kermit Script Output Out of Order

    Hopefully this group is still monitored...

    I have been developing a kermit script. I have found that when a run the
    script normally from a linux prompt that the output is mostly in order. But
    if I fork a process and run the script from a C++ program the output is in
    realtime for the AT responces but the script echo lines and the help text
    output is not dumped until the process is killed or dies.

    I notices the same order of output with the stdout redirected and captured
    to a file at the linux command prompt.

    Anyone know why? And how to get the output os the echo statements to be dump
    before the script dies or is killed?

    Thanks,
    Robert



  2. Re: Kermit Script Output Out of Order

    On 2004-10-19, Robert Simmons wrote:
    : Hopefully this group is still monitored...
    :
    Of course.

    : I have been developing a kermit script. I have found that when a run the
    : script normally from a linux prompt that the output is mostly in order. But
    : if I fork a process and run the script from a C++ program the output is in
    : realtime for the AT responces but the script echo lines and the help text
    : output is not dumped until the process is killed or dies.
    :
    : I notices the same order of output with the stdout redirected and captured
    : to a file at the linux command prompt.
    :
    : Anyone know why? And how to get the output os the echo statements to be dump
    : before the script dies or is killed?
    :
    C-Kermit was not really intended to be controlled by another process.
    When you use Kermit itself as your scripting tool, which is adequate for
    most purposes:

    http://www.columbia.edu/kermit/ckscripts.html

    you don't get the jumbled output.

    For historical (and to some extent practical) reasons, there is a mixture
    of buffered and unbuffered writes to stdout. If your process is reading
    C-Kermit's stdout, maybe it needs to read it in unbuffered mode?

    - Frank

  3. Re: Kermit Script Output Out of Order


    Okay... I'll look into the buffered vs. unbuffered mode. But what about the
    output when it is redirected to a file. The output from kermit is out of
    order there as well.

    Robert


    "Frank da Cruz" wrote in message
    news:slrncnan01.3s1.fdc@sesame.cc.columbia.edu...
    > On 2004-10-19, Robert Simmons wrote:
    > : Hopefully this group is still monitored...
    > :
    > Of course.
    >
    > : I have been developing a kermit script. I have found that when a run

    the
    > : script normally from a linux prompt that the output is mostly in order.

    But
    > : if I fork a process and run the script from a C++ program the output is

    in
    > : realtime for the AT responces but the script echo lines and the help

    text
    > : output is not dumped until the process is killed or dies.
    > :
    > : I notices the same order of output with the stdout redirected and

    captured
    > : to a file at the linux command prompt.
    > :
    > : Anyone know why? And how to get the output os the echo statements to be

    dump
    > : before the script dies or is killed?
    > :
    > C-Kermit was not really intended to be controlled by another process.
    > When you use Kermit itself as your scripting tool, which is adequate for
    > most purposes:
    >
    > http://www.columbia.edu/kermit/ckscripts.html
    >
    > you don't get the jumbled output.
    >
    > For historical (and to some extent practical) reasons, there is a mixture
    > of buffered and unbuffered writes to stdout. If your process is reading
    > C-Kermit's stdout, maybe it needs to read it in unbuffered mode?
    >
    > - Frank




  4. Re: Kermit Script Output Out of Order

    Robert Simmons wrote:

    > Okay... I'll look into the buffered vs. unbuffered mode. But what about the
    > output when it is redirected to a file. The output from kermit is out of
    > order there as well.
    >
    > Robert


    Don't try piping the output of two processes into the same file
    and you won't have issues with output being out of order.

    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  5. Re: Kermit Script Output Out of Order

    I am not piping the output of two processes to one file. I tried the piping
    of the output of only the kermit script to help debug the weird behaviour I
    was seeing in the output during the fork of the script from the C++ process.

    As you can see below the line "Hello and welcome to csd_send_script.ksc!"
    should be output well before "NO CARRIER" since it takes about 15 seconds
    for NO CARRIER to be determined.

    Here is by script and output file with the command used to redirect.

    [root:CDragon-99 robertls]# cat csd_send_script.ksc
    #!/usr/bin/kermit +

    echo Hello and welcome to csd_send_script.ksc!\10
    echo Speed: \%1\10
    echo Init String: \%2\10
    echo Called Number: \%3\10
    echo Port: \%4\10
    echo Number of Transfer: \%5\10
    echo Transfer File Path: \%6\10

    trace /on all
    set port \%4
    if fail exit 1 Cannot open \%4
    echo Using port \%4\13
    #set modem type hayes-high-speed
    #set hints off
    set modem type hayes-2400
    set speed \%1
    echo Speed set to \%1\10
    set carrier-watch off
    set flow-control rts/cts
    set transfer slow-start off
    set receive packet-length 1500
    set transfer display crt
    set modem name QualComm_CSD
    set modem hangup-method rs232-signal
    set modem command hardware-flow AT+ IFC=2,2\{13}
    set modem speed-matching off
    set transfer interruption off
    set input echo on
    set modem command init-string \%2\13
    if fail exit 1 Cannot communicate with modem
    echo Dialing \%3\10
    set dial display on
    dial \%3\13
    #output atdt 9045554444\13
    #wait 5 cd
    if fail exit 1 Cannot make data call

    set count \%5
    :loop
    echo Sending File. Transfer Count: \v(count)\10
    send \%6
    if success echo Send File #\v(count) complete\10
    if fail echo Failed Sending File #\v(count)
    if count goto loop
    bye
    hangup
    echo CSD Send Session Complete.\10
    exit 0 CSD Send Session Complete.

    [root:CDragon-99 robertls]# ./csd_send_script.ksc 115200 AT+CMUX=2
    9049440006 /dev/ttyR5 1 robert > robtemp.err 2>&1
    [root:CDragon-99 robertls]# cat robtemp.err
    ATQ0
    OK
    AT+ IFC=2,2
    OK
    AT+CMUX=2
    OK
    ATM1L2
    OK
    ATS7=70
    OK
    ATD9049440006

    NO CARRIER
    Hello and welcome to csd_send_script.ksc!

    Speed: 115200

    Init String: AT+CMUX=2

    Called Number: 9049440006

    Port: /dev/ttyR5

    Number of Transfer: 1

    Transfer File Path: robert

    TRACE ON
    Using port /dev/ttyR5
    Speed set to 115200

    Dialing 9049440006

    Hangup OK
    Initializing: 21:30:30...
    ATQ0
    Dialing: 21:30:31...
    DIAL Failure: 21:30:47: "NO CARRIER"

    *************************
    DIAL-class command failed.
    Modem type: hayes-2400
    Device: /dev/ttyR5
    Speed: 115200
    Dial status: 23 [No carrier]
    . Are you sure you have chosen the appropriate modem type?
    . Maybe the interface speed (115200) is too fast:
    SET SPEED to a lower speed and try again.
    SET SPEED ? to see the list of valid speeds.
    . SET MODEM HANGUP-METHOD MODEM-COMMAND and try again.
    . If that doesn't work, try again with SET DIAL HANGUP OFF.
    . SHOW COMMUNICATIONS, SHOW MODEM, SHOW DIAL to see current settings.
    . HELP SET MODEM, HELP SET DIAL, and HELP DIAL for more information.
    (Use SET HINTS OFF to suppress future hints.)
    *************************

    Cannot make data call
    [1] -F: "/home/robertls/csd_send_script.ksc"
    [root:CDragon-99 robertls]#


    "Jeffrey Altman" wrote in message
    news:_mfdd.83561$Ot3.22349@twister.nyc.rr.com...
    > Robert Simmons wrote:
    >
    > > Okay... I'll look into the buffered vs. unbuffered mode. But what about

    the
    > > output when it is redirected to a file. The output from kermit is out

    of
    > > order there as well.
    > >
    > > Robert

    >
    > Don't try piping the output of two processes into the same file
    > and you won't have issues with output being out of order.
    >
    > --
    > -----------------
    > This e-mail account is not read on a regular basis.
    > Please send private responses to jaltman at mit dot edu




  6. Re: Kermit Script Output Out of Order

    On 2004-10-20, Robert Simmons wrote:
    : I am not piping the output of two processes to one file. I tried the piping
    : of the output of only the kermit script to help debug the weird behaviour I
    : was seeing in the output during the fork of the script from the C++ process.
    :
    : As you can see below the line "Hello and welcome to csd_send_script.ksc!"
    : should be output well before "NO CARRIER" since it takes about 15 seconds
    : for NO CARRIER to be determined.
    :
    It's what I said: ECHO is buffered, whereas SET DIAL DISPLAY ON output is
    not. By the way, Kermit has had FOR (and WHILE) loops for many years, so
    you don't need the old SET COUNT / IF COUNT trick any more:

    : set count \%5
    ::loop
    : echo Sending File. Transfer Count: \v(count)\10
    : send \%6
    : if success echo Send File #\v(count) complete\10
    : if fail echo Failed Sending File #\v(count)
    : if count goto loop

    Why are you sending the same file repeatedly? Something like this
    looks more sensible:

    set flag off
    for \%i 1 \%5 1 {
    send \%6
    if success break
    echo "\%6: Failed - Try #\%i..."
    }
    if != \v(xferstatus) { ... } # 0 means success

    - Frank

  7. Re: Kermit Script Output Out of Order

    I tried the fork with the stdout and stdin unbuffered. But this had no
    effect. Probably because as you wrote the echos and help text output is
    buffered internally in kermit. Is there any way to flush the buffer for
    echo and help text? Or set it so that these are not buffered?

    Thanks for the advise on the script. I'll use it. The book I have is
    outdated. I'll use the website for more up to date info.

    As for the looping send: We are sending the same file as a soak test of the
    connection so we don't care about the content, just that the connection
    stays up and the transfers complete.

    Thanks,
    Robert


    "Frank da Cruz" wrote in message
    news:slrncnddme.qmr.fdc@sesame.cc.columbia.edu...
    > On 2004-10-20, Robert Simmons wrote:
    > : I am not piping the output of two processes to one file. I tried the

    piping
    > : of the output of only the kermit script to help debug the weird

    behaviour I
    > : was seeing in the output during the fork of the script from the C++

    process.
    > :
    > : As you can see below the line "Hello and welcome to

    csd_send_script.ksc!"
    > : should be output well before "NO CARRIER" since it takes about 15

    seconds
    > : for NO CARRIER to be determined.
    > :
    > It's what I said: ECHO is buffered, whereas SET DIAL DISPLAY ON output is
    > not. By the way, Kermit has had FOR (and WHILE) loops for many years, so
    > you don't need the old SET COUNT / IF COUNT trick any more:
    >
    > : set count \%5
    > ::loop
    > : echo Sending File. Transfer Count: \v(count)\10
    > : send \%6
    > : if success echo Send File #\v(count) complete\10
    > : if fail echo Failed Sending File #\v(count)
    > : if count goto loop
    >
    > Why are you sending the same file repeatedly? Something like this
    > looks more sensible:
    >
    > set flag off
    > for \%i 1 \%5 1 {
    > send \%6
    > if success break
    > echo "\%6: Failed - Try #\%i..."
    > }
    > if != \v(xferstatus) { ... } # 0 means success
    >
    > - Frank




  8. Re: Kermit Script Output Out of Order

    On 2004-10-20, Robert Simmons wrote:
    : I tried the fork with the stdout and stdin unbuffered. But this had no
    : effect. Probably because as you wrote the echos and help text output is
    : buffered internally in kermit. Is there any way to flush the buffer for
    : echo and help text? Or set it so that these are not buffered?
    :
    There is no universal setting to make all output the same (buffered or
    unbuffered). This could be added, but it would be a very big job.

    Well, there IS one thing you might try. If you can build from source,
    you can recompile as follows:

    make clean
    make linux (or whatever) "KFLAGS=-DNONOSETBUF"

    This is supposed to make all output unbuffered. You probably won't like
    the result, but at least it should be synchronized. (I can't guarantee this
    will work, as some of the setbuf() calls are pretty deeply embedded in
    #ifdefs, but failing that, just add "setbuf(stdout,NULL);" to some part of
    sysinit() in ckutio.c, that is not conditionally compiled.)

    Let us know the results; if favorable, I suppose this could be converted
    from a compile-time option to a runtime setting.

    : Thanks for the advise on the script. I'll use it. The book I have is
    : outdated. I'll use the website for more up to date info.
    :
    : As for the looping send: We are sending the same file as a soak test of the
    : connection so we don't care about the content, just that the connection
    : stays up and the transfers complete.
    :
    Here's an undocumented feature you might want to use for testing and
    benchmarking:

    SEND /CALIBRATE:xxx

    This creates a random-content uncompressable dummy file on the fly for
    sending, of length xxx K bytes.

    - Frank

  9. Re: Kermit Script Output Out of Order

    Well, I learn something new every day
    I guess I should have found this poking around in the source, but a cool
    thing to know.


    >
    > SEND /CALIBRATE:xxx
    >
    > This creates a random-content uncompressable dummy file on the fly for
    > sending, of length xxx K bytes.
    >
    > - Frank




+ Reply to Thread