Screen Capture - Protocols

This is a discussion on Screen Capture - Protocols ; I am just getting my feet wet using c-kermit, Debian Sarge, and a VT520, to run useful scripts on a serial connection to another computer. Capturing data and printing it would be useful. It seems the "screen scrape script" on ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Screen Capture

  1. Screen Capture

    I am just getting my feet wet using c-kermit, Debian Sarge, and a VT520,
    to run useful scripts on a serial connection to another computer.

    Capturing data and printing it would be useful.
    It seems the "screen scrape script" on the kermit site is for kermit95.

    What kermit or Linux command do I want to investigate for this?

  2. Re: Screen Capture

    In article ,
    2damn <2damn@nospam.com> wrote:
    >I am just getting my feet wet using c-kermit, Debian Sarge, and a VT520,
    >to run useful scripts on a serial connection to another computer.
    >
    >Capturing data and printing it would be useful.
    >It seems the "screen scrape script" on the kermit site is for kermit95.
    >
    >What kermit or Linux command do I want to investigate for this?


    Kermit has the 'log' command that will provide various kinds of gory
    detail to a file. 'log session' before a 'connect' command, and you
    wil capture all the interactive stuff you do, and which you can use
    to built a script from.


    This approach fails if the remote system thinks its talking to something
    where it can play cursor-positioning and selective over-write games.

    If you can tell the remote computer that you're using some kind of a 'dumb'
    hard-copy terminal this issue is moot.

    Else, screen-scraping gets *VERY* complex.

  3. Re: Screen Capture

    In article ,
    2damn@nospam.com says...
    > I am just getting my feet wet using c-kermit, Debian Sarge, and a VT520,
    > to run useful scripts on a serial connection to another computer.
    >
    > Capturing data and printing it would be useful.
    > It seems the "screen scrape script" on the kermit site is for kermit95.
    >
    > What kermit or Linux command do I want to investigate for this?
    >


    I take it you want to "screen scrape" the VT520?

    Does the 520 have a "print screen" feature? (Most/all of
    the earlier VT series terminals did.) If so, you could
    direct the "print screen" to the terminal's printer port,
    and connect the printer port via a null modem cable to a
    computer, for example to a spare serial port on your Debian
    Unix system. Run a suitable serial-port application that
    is capturing input on the 2nd serial port (say, for example,
    C-Kermit), and press the "print" key (probably F2) on the
    VT520 keyboard, or send the VT520 the escape sequence to
    invoke the "print screen" function. The screen contents
    should show up in the 2nd instance of Kermit's log file
    as 24 lines of 80 characters (or whatever size you've got
    the VT520 set to), just as if it was sent to a real serial
    printer.


    --
    John

  4. Re: Screen Capture

    On Wed, 05 Dec 2007 17:50:19 +0000, John Santos wrote:

    > I take it you want to "screen scrape" the VT520?


    If I am using the correct terms, yes.

    > Does the 520 have a "print screen" feature? (Most/all of the earlier VT
    > series terminals did.) If so, you could direct the "print screen" to
    > the terminal's printer port, and connect the printer port via a null
    > modem cable to a computer, for example to a spare serial port on your
    > Debian Unix system. Run a suitable serial-port application that is
    > capturing input on the 2nd serial port (say, for example, C-Kermit), and
    > press the "print" key (probably F2) on the VT520 keyboard, or send the
    > VT520 the escape sequence to invoke the "print screen" function. The
    > screen contents should show up in the 2nd instance of Kermit's log file
    > as 24 lines of 80 characters (or whatever size you've got the VT520 set
    > to), just as if it was sent to a real serial printer.


    I hope to capture screen data from a kermit script without manually
    pressing a key. Thank you for your response. I am still trying to find
    something that works. See my reply above for my current attempts.


  5. Re: Screen Capture

    On Mon, 03 Dec 2007 03:47:21 +0000, Robert Bonomi wrote:

    > In article , 2damn
    > <2damn@nospam.com> wrote:
    > Kermit has the 'log' command that will provide various kinds of gory
    > detail to a file. 'log session' before a 'connect' command, and you wil
    > capture all the interactive stuff you do, and which you can use to
    > built a script from.
    >
    >
    > This approach fails if the remote system thinks its talking to something
    > where it can play cursor-positioning and selective over-write games.
    >
    > If you can tell the remote computer that you're using some kind of a
    > 'dumb' hard-copy terminal this issue is moot.
    >
    > Else, screen-scraping gets *VERY* complex.


    I tried "log" and it does contain communication data that is not useful
    for me. And some bits are total garbage so there may be some of what you
    mention in your second paragraph going on.

    I have found that "cat /dev/vcsX" can copy ttyX, but of course not my
    ttySX. I can format the capture with newlines (dd) and trim what I want
    (sed). Attempting to get it to work on the serial lines.

  6. Re: Screen Capture

    On 2007-12-12, 2damn <2damn@nospam.com> wrote:
    : On Mon, 03 Dec 2007 03:47:21 +0000, Robert Bonomi wrote:
    :> In article , 2damn
    :> <2damn@nospam.com> wrote:
    :> Kermit has the 'log' command that will provide various kinds of gory
    :> detail to a file. 'log session' before a 'connect' command, and you wil
    :> capture all the interactive stuff you do, and which you can use to
    :> built a script from.
    :>
    :> This approach fails if the remote system thinks its talking to something
    :> where it can play cursor-positioning and selective over-write games.
    :>
    :> If you can tell the remote computer that you're using some kind of a
    :> 'dumb' hard-copy terminal this issue is moot.
    :>
    :> Else, screen-scraping gets *VERY* complex.
    :
    : I tried "log" and it does contain communication data that is not useful
    : for me. And some bits are total garbage so there may be some of what you
    : mention in your second paragraph going on.
    :
    The garbage is mostly likely escape sequences and control characters from the
    host application.

    : I have found that "cat /dev/vcsX" can copy ttyX, but of course not my
    : ttySX.
    :
    That would be the same as Kermit's session log -- it's just a copy of the
    incoming data stream.

    : I can format the capture with newlines (dd) and trim what I want
    : (sed). Attempting to get it to work on the serial lines.
    :
    As explained here:

    http://www.columbia.edu/kermit/ckfaq.html#term

    C-Kermit (unlike Kermit 95 on Windows) is not a terminal emulator; it's a
    communications pipe between the remote system and your terminal window or
    console driver, the latter being the component that handles the terminal
    emulation.

    If your terminal emulation is ANSI-compliant (such as VT100, VT220, etc),
    we have a utility for stripping escape sequences from session logs:

    http://www.columbia.edu/kermit/ftp/utils/rmescseq.c

    It doesn't interpret the escape sequences, it just removes them.

    - Frank

  7. Re: Screen Capture

    In article ,
    2damn <2damn@nospam.com> wrote:
    >On Mon, 03 Dec 2007 03:47:21 +0000, Robert Bonomi wrote:
    >
    >> In article , 2damn
    >> <2damn@nospam.com> wrote:
    >> Kermit has the 'log' command that will provide various kinds of gory
    >> detail to a file. 'log session' before a 'connect' command, and you wil
    >> capture all the interactive stuff you do, and which you can use to
    >> built a script from.
    >>
    >>
    >> This approach fails if the remote system thinks its talking to something
    >> where it can play cursor-positioning and selective over-write games.
    >>
    >> If you can tell the remote computer that you're using some kind of a
    >> 'dumb' hard-copy terminal this issue is moot.
    >>
    >> Else, screen-scraping gets *VERY* complex.

    >
    >I tried "log" and it does contain communication data that is not useful
    >for me. And some bits are total garbage so there may be some of what you
    >mention in your second paragraph going on.
    >
    >I have found that "cat /dev/vcsX" can copy ttyX, but of course not my
    >ttySX. I can format the capture with newlines (dd) and trim what I want
    >(sed). Attempting to get it to work on the serial lines.



    OK, bluntly, given your descriptions, _you_ cannot get C-Kermit to do that
    which you want to happen.

    Building application-specific 'screen-scraping' logic in Kermit macro-language
    *is* possible, but *very* _painful_, and works only for the exact screen
    form for which it was coded. If _anything_ changes regarding how the remote
    machine generates the screen, the macro programming requires major reworking.

    Developing such macros requires an *intimate*knowledge* of what the remote
    machine is doing, and what kind of device it 'thinks' it is talking to, *AND*
    the gory details of the formatting/addressing protocol(s) being used. And if
    the remote machine's concept of the terminal device can be changed or not.
    Also, if it can be changed, what are _all_ the possible alternatives.

    As you apparently lack this essential information about the environment you
    are trying to work in, and don't have the experience to simply 'recognize on
    sight' the protocol data in what you have described as the 'total garbage',
    you do not have the required skill-set to build the solution you need.
    (This _is_ "specialist" knowledge/skills -- unless you routinely do work
    involving 'faking a terminal', it's not surprising that you don't know these
    things -- they're *not* part of the 'general skills'. )

    Your best bet is to hire a knowledgeable professional -- one _with_ expertise
    in 'serial port communications' -- for (A) a consultation on 'what is
    going on' in your specific situation, (B) 'what is practical' as regards
    EXACTLY what you are trying to accomplish, and then, possibly (C) development
    of custom software -- probably not based on Kermit -- to solve your problem.


    Feel free to e-mail me directly with further questions. Please start the
    subject line with 'KERMIT', so I'll see it.



  8. Re: Screen Capture

    I reply without quoting your whole response.

    Your assessment is right on target.

    My current self made project is to use kermit to automate some tasks on
    serial connections to a company system. Just to speed things up and save
    some carpal tunnel. I do not have and will not have any sort of
    administrator rights on the company system. I am just trying to have the
    kermit input and output commands run repetitive tasks. The problem is
    there are many exceptions to default scenarios and I think kermit can
    deal with them.

    I am having success with some aspects so far. Screen capture would be
    great to add.

    I am not a professional programmer or serial communications expert by any
    means.

    I will kick the dead mule a while longer.



  9. Re: Screen Capture

    On 2007-12-14, 2damn <2damn@nospam.com> wrote:
    : My current self made project is to use kermit to automate some tasks on
    : serial connections to a company system. Just to speed things up and save
    : some carpal tunnel. I do not have and will not have any sort of
    : administrator rights on the company system. I am just trying to have the
    : kermit input and output commands run repetitive tasks. The problem is
    : there are many exceptions to default scenarios and I think kermit can
    : deal with them.
    :
    C-Kermit can handle text-mode dialogs just fine, and for that matter also
    menu-driven dialogs, if you can do this without specific reference to screen
    positions and coordinates. For example, the host application paints a
    manu and at the bottom it prints "Choice?" and the user is supposed to enter
    the number (or whatever) of the desired menu item. Well, if "Choice?" is
    the last thing that the host sends (which is something you can tell from
    a session log), then:

    clear input
    input 10 Choice?
    if failure (do something)
    output 3\13

    is all you need for waiting for the menu to paint itself (assuming it does
    so within 10 seconds) and to choose menu item number 3.

    On the other hand, if you really need to reference specific screen
    coordinates or the contents of specifi screen fields
    , you can do this with Kermit 95 on Windows because, unlike
    C-Kermit, in incorporates its own terminal emulator and knows what is on the
    screen and where.

    Perhaps if you describe a typical session of the type you want to automate,
    I can show you how to do it. Meanwhile, take a look at the brief Kermit
    scripting tutorial here:

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

    and the many sample scripts that are included in the script library, listed
    on the same page.

    - Frank

  10. Re: Screen Capture

    In article ,
    2damn@nospam.com says...
    > On Wed, 05 Dec 2007 17:50:19 +0000, John Santos wrote:
    >
    > > I take it you want to "screen scrape" the VT520?

    >
    > If I am using the correct terms, yes.
    >
    > > Does the 520 have a "print screen" feature? (Most/all of the earlier VT
    > > series terminals did.) If so, you could direct the "print screen" to
    > > the terminal's printer port, and connect the printer port via a null
    > > modem cable to a computer, for example to a spare serial port on your
    > > Debian Unix system. Run a suitable serial-port application that is
    > > capturing input on the 2nd serial port (say, for example, C-Kermit), and
    > > press the "print" key (probably F2) on the VT520 keyboard, or send the
    > > VT520 the escape sequence to invoke the "print screen" function. The
    > > screen contents should show up in the 2nd instance of Kermit's log file
    > > as 24 lines of 80 characters (or whatever size you've got the VT520 set
    > > to), just as if it was sent to a real serial printer.

    >
    > I hope to capture screen data from a kermit script without manually
    > pressing a key. Thank you for your response. I am still trying to find
    > something that works. See my reply above for my current attempts.


    I believe there is an escape sequence that can be sent to the terminal
    to do the same thing as pressing the "print screen" key. I didn't
    want to complicate the original post by going into that. If your
    program knows when to screen scrape, it can send the sequence at the
    appropriate time. If the program doesn't know when to do it, and the
    user has to press a key. Otherwise, how do you expect it to happen?

    --
    John

  11. Re: Screen Capture

    On Sun, 16 Dec 2007 07:48:12 +0000, John Santos wrote:
    > I believe there is an escape sequence that can be sent to the terminal
    > to do the same thing as pressing the "print screen" key. I didn't want
    > to complicate the original post by going into that. If your program
    > knows when to screen scrape, it can send the sequence at the appropriate
    > time. If the program doesn't know when to do it, and the user has to
    > press a key. Otherwise, how do you expect it to happen?


    This is a great suggestion I had not really considered. I will try it out
    this week.



  12. Re: Screen Capture

    On 2007-12-17, 2damn <2damn@nospam.com> wrote:
    : On Sun, 16 Dec 2007 07:48:12 +0000, John Santos wrote:
    :> I believe there is an escape sequence that can be sent to the terminal
    :> to do the same thing as pressing the "print screen" key. I didn't want
    :> to complicate the original post by going into that. If your program
    :> knows when to screen scrape, it can send the sequence at the appropriate
    :> time. If the program doesn't know when to do it, and the user has to
    :> press a key. Otherwise, how do you expect it to happen?
    :
    : This is a great suggestion I had not really considered. I will try it out
    : this week.
    :
    C-Kermit supports this; see:

    http://www.columbia.edu/kermit/ckermit70.html#x3.3

    - Frank

  13. Re: Screen Capture

    On Fri, 14 Dec 2007 17:49:47 +0000, Frank da Cruz wrote:
    > C-Kermit can handle text-mode dialogs just fine, and for that matter
    > also menu-driven dialogs, if you can do this without specific reference
    > to screen positions and coordinates. For example, the host application
    > paints a manu and at the bottom it prints "Choice?" and the user is
    > supposed to enter the number (or whatever) of the desired menu item.
    > Well, if "Choice?" is the last thing that the host sends (which is
    > something you can tell from a session log), then:
    >
    > clear input
    > input 10 Choice?
    > if failure (do something)
    > output 3\13


    I have the input, if failure, output routine going okay. I am currently
    using a generic FAIL message and will add better notices where needed.

    The trouble is that each feature is not exactally the same at all times.
    As I said I think kermit can deal with this. At the very least, well
    enough to send unsolvable items to an error report.

    > On the other hand, if you really need to reference specific screen
    > coordinates or the contents of specifi screen fields , you can do this
    > with Kermit 95 on Windows because, unlike C-Kermit, in incorporates its
    > own terminal emulator and knows what is on the screen and where.


    The system accepts commands just fine so long as I can compensate for
    some differences. The issue with garbled feedback applies only to "screen
    grabs". Using the kermit session record some "screens" just have
    "interuptions" with serial communication data and some seem completely
    broken and unrecognizable. I think the kermit session logging is not the
    way for me to correctly capture the feedback from the system.

    The ability to "screen grab" is very secondary to kermit being useful for
    my project.

    This week I have individual items running through 2 processes from a list
    thanks to the online kermit documentation. Adding an option for a third
    process and a useable kermit or bash menu will bring it up to snuff as a
    beta usable to others.

    Thanks for all the info so far.



  14. Re: Screen Capture

    On 2007-12-20, 2damn <2damn@nospam.com> wrote:
    : On Fri, 14 Dec 2007 17:49:47 +0000, Frank da Cruz wrote:
    :> C-Kermit can handle text-mode dialogs just fine, and for that matter
    :> also menu-driven dialogs, if you can do this without specific reference
    :> to screen positions and coordinates. For example, the host application
    :> paints a manu and at the bottom it prints "Choice?" and the user is
    :> supposed to enter the number (or whatever) of the desired menu item.
    :> Well, if "Choice?" is the last thing that the host sends (which is
    :> something you can tell from a session log), then:
    :>
    :> clear input
    :> input 10 Choice?
    :> if failure (do something)
    :> output 3\13
    :
    : I have the input, if failure, output routine going okay. I am currently
    : using a generic FAIL message and will add better notices where needed.
    :
    : The trouble is that each feature is not exactally the same at all times.
    : As I said I think kermit can deal with this. At the very least, well
    : enough to send unsolvable items to an error report.
    : ...
    : The system accepts commands just fine so long as I can compensate for
    : some differences. The issue with garbled feedback applies only to "screen
    : grabs". Using the kermit session record some "screens" just have
    : "interuptions" with serial communication data and some seem completely
    : broken and unrecognizable. I think the kermit session logging is not the
    : way for me to correctly capture the feedback from the system.
    :
    Session logging has nothing to do with scripting. If your script is
    supposed to be interacting with a remote menu or whatever, then the script
    uses INPUT to read incoming material and reacts to it with OUTPUT.

    But any form of scripting relies on the messages, prompts, menus, etc,
    being received intact. If you can't predict what is going to come, how can
    you reasonably write a script to react to it?

    If you have a network connection, there should be no garbling because
    network protocols take care of error correction and flow control. If you
    have a serial port or modem and you're getting garbage, you need to fix
    the garbage. If it's a modem, you need to be using an error-detecting and
    -correcting protocol between the two modems, and then (mode or direct
    connection) you need to have the most effective possible form of flow
    control enabled, which normally would be RTS/CTS (a.k.a. "hardware flow
    control").

    : This week I have individual items running through 2 processes from a list
    : thanks to the online kermit documentation. Adding an option for a third
    : process and a useable kermit or bash menu will bring it up to snuff as a
    : beta usable to others.
    :
    : Thanks for all the info so far.
    :
    Sure. And remember, the more specifics you give about your connection,
    the behavior of the applicaiton you're scripting, etc, the better we can
    help you.

    - Frank

+ Reply to Thread