L-D'Ambrosio@dmr.asa.com (Louis D'Ambrosio) (05/11/91)
To Everyone and Anyone!
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.
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.
I have some skill in "C" but this is beyond me so any help
would be appretiated.
Thanks!
-Lougemini@geminix.in-berlin.de (Uwe Doering) (05/11/91)
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. You can't monitor DTR because it's not an input line. It is an output and can be controlled by a C program. But I think that's not what you wanted. For further informations, look at the termio(7) man page. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
les@chinet.chi.il.us (Leslie Mikesell) (05/12/91)
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
root@ms.uky.edu (1.4142135623730950488016887242096) (05/12/91)
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. DTR is driven by the computer (the [D]ata [T]erminal) and goes high when the serial port is opened. The device attached to the port drives DCD and/or DSR (depends on the device) to signal that it is ready to exchange data. If you are looking for somebody to dial into a modem or something similar, you probably want one of these signals. If you are really monitoring for a process on your machine to open the serial port, there is probably an easier way to do it than to fudge the hardware directly. -- Kenneth Herron kherron@ms.uky.edu University of Kentucky (606) 257-2975 Department of Mathematics "P.S.: Please excuse the lateness of my reply." -- Ringo Starr
lh@aega84.UUCP (L. Hirschbiegel) (05/15/91)
In article <XKTQY0O@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: > >You can't monitor DTR because it's not an input line. It is an >output and can be controlled by a C program. But I think that's >not what you wanted. > > Uwe What's that??? As far as I recall the specifications, DTR is an output line for DTE's but it might as well be an input line for DCE's ! The same is obviously valid for DSR. L. Hirschbiegel -- ==================================================================== L. Hirschbiegel, AEG Produktionsautomatisierung, Frankfurt (Germany) unido!aega84!lh -49-69-66414316 ====================================================================
gemini@geminix.in-berlin.de (Uwe Doering) (05/15/91)
lh@aega84.UUCP (L. Hirschbiegel) writes: >In article <XKTQY0O@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >> >>You can't monitor DTR because it's not an input line. It is an >>output and can be controlled by a C program. But I think that's >>not what you wanted. >> >> Uwe > > What's that??? As far as I recall the specifications, DTR is an output > line for DTE's but it might as well be an input line for DCE's ! > The same is obviously valid for DSR. Yes, but a computer is usually a DTE, and therefore DTR is an output. On a DCE (a modem, for instance), DTR is of course an input. What the original author wanted was to monitor DTR from a C program running on his computer. And, for obvious reasons, this isn't possible. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
lothar@tmcsys.UUCP (L. Hirschbiegel) (05/16/91)
In article <GVXQ4LC@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >lh@aega84.UUCP (L. Hirschbiegel) writes: > >>In article <XKTQY0O@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >>> >Yes, but a computer is usually a DTE, and therefore DTR is an output. >On a DCE (a modem, for instance), DTR is of course an input. > > Uwe >-- This is amazing. "A computer" isn't necessarily a DTE, not even in the PC world you refer to (I guess). I've checked all dumb and intelligent cards that I have access to: - "dumb" serial PC card is DTE (but in most cases nowadays changable to DCE by jumpers) - ACE is wired as DCE - Chase AT4 is wired as DCE - Specialix 8 port is wired as DCE By the way: my modem is wired as DTE (bad world, isn't it ? :-) Lothar -- ----------------------------------------------- L. Hirschbiegel, AEG - A84, Frankfurt (Germany) email: unido!aega84!lh tel: -49-69-66414316 -----------------------------------------------