Looking for a more clever solution

[tony@aplawrence.com]

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).

My thought is that I have to write a happy little fake serial port
driver that will pretend everything is just as it should be and then
suck up the data for me.

My inability to think of anything else is hopefully not an indication
that there isn't an easier way.

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

[Eric Nicholson (NewsGroup)]

[email]tony@aplawrence.com[/email] typed (on Fri, Aug 01, 2003 at 05:51:07PM +0000):
|
| 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).
|
| My thought is that I have to write a happy little fake serial port
| driver that will pretend everything is just as it should be and then
| suck up the data for me.
|
| My inability to think of anything else is hopefully not an indication
| that there isn't an easier way.
|
| --
| [email]tony@aplawrence.com[/email] Unix/Linux/Mac OS X resources: [url]http://aplawrence.com[/url]
| Get paid for writing about tech: [url]http://aplawrence.com/publish.html[/url]

Just a quick thought, but, how about emailing a message from the system
or app to the cell phone since most cell phones except text email messages
as well.


--
Eric Nicholson, - [email]ericn@cactus.com[/email]
Lone Star Software Corp.

[tony@aplawrence.com]

"Eric Nicholson (NewsGroup)" <ericn@cactus.com> wrote:

>tony@aplawrence.com typed (on Fri, Aug 01, 2003 at 05:51:07PM +0000):
>|
>| 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).
>|
>| My thought is that I have to write a happy little fake serial port
>| driver that will pretend everything is just as it should be and then
>| suck up the data for me.
>|
>| My inability to think of anything else is hopefully not an indication
>| that there isn't an easier way.
>|
>| --
>| [email]tony@aplawrence.com[/email] Unix/Linux/Mac OS X resources: [url]http://aplawrence.com[/url]
>| Get paid for writing about tech: [url]http://aplawrence.com/publish.html[/url]

>Just a quick thought, but, how about emailing a message from the system
>or app to the cell phone since most cell phones except text email messages
>as well.

Yes, that's what I intend to do. The problem is that the app wants
to do ioctl's on a serial device as I explained. I have to get around
THAT. The rest is simple.

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

[tony@aplawrence.com]

Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

>On Fri, 1 Aug 2003 17:51:07 +0000 (UTC), [email]tony@aplawrence.com[/email] 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.

....

>2- Connect one serial port to another one, and write a small app to
>read from that second port and to reply as the app expects, and then
>make that new app to send to the cell phone in a more suitable way.
>This should not be too dificult to do.

See, I told you there was a better idea out there!

Thanks.

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

[John DuBois]

In article <bge9ab$hq4$2@pcls4.std.com>, <tony@aplawrence.com> 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).
>
>My thought is that I have to write a happy little fake serial port
>driver that will pretend everything is just as it should be and then
>suck up the data for me.
>
>My inability to think of anything else is hopefully not an indication
>that there isn't an easier way.

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

John
--
John DuBois [email]spcecdt@armory.com[/email] KC6QKZ/AE [url]http://www.armory.com/~spcecdt/[/url]

[tony@aplawrence.com]

John DuBois <spcecdt@deeptht.armory.com> wrote:

>In article <bge9ab$hq4$2@pcls4.std.com>, <tony@aplawrence.com> 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


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

[John DuBois]

In article <bgljj8$c82$1@pcls4.std.com>, <tony@aplawrence.com> wrote:

>John DuBois <spcecdt@deeptht.armory.com> wrote:

>>In article <bge9ab$hq4$2@pcls4.std.com>, <tony@aplawrence.com> 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 [email]spcecdt@armory.com[/email] KC6QKZ/AE [url]http://www.armory.com/~spcecdt/[/url]

[tony@aplawrence.com]

In comp.unix.sco.misc John DuBois <spcecdt@deeptht.armory.com> wrote:

>In article <bgljj8$c82$1@pcls4.std.com>, <tony@aplawrence.com> wrote:

>>John DuBois <spcecdt@deeptht.armory.com> wrote:

>>>In article <bge9ab$hq4$2@pcls4.std.com>, <tony@aplawrence.com> 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!

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