Re: Looking for a more clever solution - SCO

This is a discussion on Re: Looking for a more clever solution - SCO ; John DuBois wrote: >In article , wrote: >> >>I have a client with an app that uses a modem to page technicians. >> >>Doesn't want to do that; wants to sdend the data to their cell phone >>instead. >> >>Unfortunately, ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Looking for a more clever solution

  1. Re: Looking for a more clever solution

    John DuBois wrote:
    >In article , wrote:
    >>
    >>I have a client with an app that uses a modem to page technicians.
    >>
    >>Doesn't want to do that; wants to sdend the data to their cell phone
    >>instead.
    >>
    >>Unfortunately, app apparently does more than just open the port
    >>and send AT commands. Looks like it is actually doing ioctl stty's
    >>and expecting happy results. App vendor (of course) is unhelpful
    >>so far; wants customer to upgrade to Windows (which he'll happily
    >>do when hell freezes solid, or so he says).
    >>


    >Tell the app to use a pty. Have a daemon listen to the master side for
    >messages.


    Hmm. I never realized I could do that. I always thought you had to
    open both, exec what you wanted to read on the slave, and read/write
    from the master.

    Searching Google for examples that don't follow that model has been
    fruitless, and so far my experimentation with simple tests hasn't
    let me read from ptyx anything written to ttyx.. can you give a
    simple example?

    Probably should move this to c.u.s.p


    --
    tony@aplawrence.com Unix/Linux/Mac OS X resources: http://aplawrence.com
    Get paid for writing about tech: http://aplawrence.com/publish.html

  2. Re: Looking for a more clever solution

    In article , wrote:
    >John DuBois wrote:
    >>In article , wrote:
    >>>
    >>>I have a client with an app that uses a modem to page technicians.
    >>>
    >>>Doesn't want to do that; wants to sdend the data to their cell phone
    >>>instead.
    >>>
    >>>Unfortunately, app apparently does more than just open the port
    >>>and send AT commands. Looks like it is actually doing ioctl stty's
    >>>and expecting happy results. App vendor (of course) is unhelpful
    >>>so far; wants customer to upgrade to Windows (which he'll happily
    >>>do when hell freezes solid, or so he says).
    >>>

    >
    >>Tell the app to use a pty. Have a daemon listen to the master side for
    >>messages.

    >
    >Hmm. I never realized I could do that. I always thought you had to
    >open both, exec what you wanted to read on the slave, and read/write
    >from the master.


    Nope. With earlier versions of the pty driver you had to open the master side
    first; in the current version you can open either. The slave side can be
    closed & reopened without having to reopen the master side. If the master side
    is closed, the slave side will see a "hangup". This works for your purposes
    because it's the master side you will want to keep constantly open, with
    messages being read from it.

    >Searching Google for examples that don't follow that model has been
    >fruitless, and so far my experimentation with simple tests hasn't
    >let me read from ptyx anything written to ttyx.. can you give a
    >simple example?
    >
    >Probably should move this to c.u.s.p


    Find a pty that isn't in use (for your purposes, you will need to reserve a
    fixed pty, perhaps by selecting a high-numbered pty and opening it early in rc2
    processing). Then (using ttyp63 for an example):

    On one screen, do:
    $ cat /dev/ptyp63

    From another screen, echo or cat to /dev/ttyp63. The above cat process should
    spit out everything you send to the slave.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  3. Re: Looking for a more clever solution

    In comp.unix.sco.misc John DuBois wrote:
    >In article , wrote:
    >>John DuBois wrote:
    >>>In article , wrote:
    >>>>
    >>>>I have a client with an app that uses a modem to page technicians.
    >>>>
    >>>>Doesn't want to do that; wants to sdend the data to their cell phone
    >>>>instead.
    >>>>
    >>>>Unfortunately, app apparently does more than just open the port
    >>>>and send AT commands. Looks like it is actually doing ioctl stty's
    >>>>and expecting happy results. App vendor (of course) is unhelpful
    >>>>so far; wants customer to upgrade to Windows (which he'll happily
    >>>>do when hell freezes solid, or so he says).
    >>>>

    >>
    >>>Tell the app to use a pty. Have a daemon listen to the master side for
    >>>messages.

    >>
    >>Hmm. I never realized I could do that. I always thought you had to
    >>open both, exec what you wanted to read on the slave, and read/write
    >>from the master.


    >Nope. With earlier versions of the pty driver you had to open the master side
    >first; in the current version you can open either. The slave side can be
    >closed & reopened without having to reopen the master side. If the master side
    >is closed, the slave side will see a "hangup". This works for your purposes
    >because it's the master side you will want to keep constantly open, with
    >messages being read from it.


    >>Searching Google for examples that don't follow that model has been
    >>fruitless, and so far my experimentation with simple tests hasn't
    >>let me read from ptyx anything written to ttyx.. can you give a
    >>simple example?
    >>
    >>Probably should move this to c.u.s.p


    >Find a pty that isn't in use (for your purposes, you will need to reserve a
    >fixed pty, perhaps by selecting a high-numbered pty and opening it early in rc2
    >processing). Then (using ttyp63 for an example):


    >On one screen, do:
    >$ cat /dev/ptyp63


    >From another screen, echo or cat to /dev/ttyp63. The above cat process should
    >spit out everything you send to the slave.


    Hmm. I tried that on my Mac while I was away for the weekend, did not
    work. I'm back home, firing up the SCO box..

    Son of a gun. Wonder what is up with BSD that makes that different.
    Oh well, this is for SCO, and that works fine. I'll look at the
    BSD stuff another day.

    Thanks John. That's such a simple thing, but I never knew it could be done!

    --
    tony@aplawrence.com Unix/Linux/Mac OS X resources: http://aplawrence.com
    Get paid for writing about tech: http://aplawrence.com/publish.html

+ Reply to Thread