Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!caen!uwm.edu!linac!midway!clout!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.questions
Subject: Re: DTR program
Message-ID: <1991May11.221811.25715@chinet.chi.il.us>
Date: 11 May 91 22:18:11 GMT
References: <26854@adm.brl.mil>
Organization: Chinet - Chicago Public Access UNIX
Lines: 64

In article <26854@adm.brl.mil> L-D'Ambrosio@dmr.asa.com (Louis D'Ambrosio) writes:

>    I've gotten involved in a project that requires a "C"
>program that can watch a given serial port and wait for DTR
>to go HI. The program would then run a script and continue
>watching the port for a drop of DTR.   If this occurs it would
>kill the script.    

Since DTR is an output lead, I'll assume you want to watch the DTR
lead from another piece of equipment.  For this you will need a
"null modem" connector which connects the DTR lead from one piece
of equipment to the DCD (carrier detect) lead of the other along
with the other appropriate connections to allow two pieces of
DTE (data terminal equipment) to talk to each other.  If you are
actually connecting to a modem (DCE) you don't need the null modem
connector and you really want to watch DCD.

>The machine I run on is a Altos 486/1000 w/Unix V v3.1, or
>if you really want to get picky Altos Unix v5.3et2.

Since a normal open of a tty device under unix waits for carrier
detect to be present before completion, most of your work is
already done.

>I have some skill in "C" but this is beyond me so any help
>would be appretiated.

On the sysV machines I've used, init is perfectly happy to spawn
a shell script, so you could just let it restart the program for
you.  The easy way to set this up is to use the sysadmin tools to
put a getty on the line, then edit the /etc/inittab file to change
the entry for your line to run your script instead of /etc/getty.
Init should arrange for your process to be a process group leader
without a controlling terminal, so when the script opens the line
it will become the controlling terminal, meaning that it will get
a sighup signal when the DTR/DCD lead drops, which will automatically
terminate your script.  Then the "respawn" in the inittab entry will
tell init to start another one, which will wait for DCD to complete
its initial open.

There are just a couple of loose ends you have to sew up. Init doesn't
automatically connect the program it starts to the port, so you either
have to use redirection in the inittab entry (script</dev/ttyn >/dev/ttyn 2>&1)
or the script must open it itself with "exec </dev/ttyn >/dev/ttyn 2>&1" or
possibly the equivalent using an argument passed on the command line as
per getty.  Next you have to set the communication speed and modes
appropriately for the device.  After you have the line open as file
descriptor 0 (stdin), you can just use stty to set the modes.
Note that the environment for the script may not be what you would
expect for an interactive user.  In particular, you may need to set
PATH yourself in the script (a good idea anyway).  Also, the script will
be running as root, which might be dangerous if there is an error in it.
You might want to invoke it as "su -c somebody script" where somebody
is the user whose permissions will be used.

Some versions of SysVr3.2 store pieces of the inittab file somewhere
as you make changes with the sysadmin tools and use the pieces to
rebuild the file at some later time.  If this is the case with the
Altos, you can't just edit /etc/inittab directly and run "init q" to
pick up the change.  In addition, you have to make the equivalent change
wherever the copy is stored (somewhere under /etc/conf/init.d/ I think).

Les Mikesell
  les@chinet.chi.il.us