Xref: utzoo comp.unix.microport:2978 comp.unix.questions:12205
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!ctisbv!pim
From: pim@ctisbv.UUCP (Pim Zandbergen)
Newsgroups: comp.unix.microport,comp.unix.questions
Subject: Re: ct on SysV386 3.0Ue
Message-ID: <712@ctisbv.UUCP>
Date: 13 Mar 89 16:45:28 GMT
References: <584@pgthor.UUCP> <7475@killer.DALLAS.TX.US> <696@nsscb.UUCP>
Reply-To: pim@ctisbv.UUCP (Pim Zandbergen)
Followup-To: comp.unix.microport
Organization: CTI Software BV, The Hague, The Netherlands
Lines: 28

In article <696@nsscb.UUCP> rhc@nsscb.UUCP (Rick Calder) writes:
>
>	The culprit is uugetty(1M).  See the manpage, it is documented as
>a bug that uugetty breaks ct.  If the modem port is idle, ie no uugetty or
>getty on it, then ct will work as advertised.

I got ct(1) working with the following line in /etc/inittab:

51:234:respawn:sh -c 'sleep 60; exec /usr/lib/uucp/uugetty -rt 60 tty51 2400'

This makes sure the line will be idle for 60 seconds after hanging up.
In my case, that is enough to have ct(1) call me back.

Another problem with ct(1), is that it looks in /usr/lib/uucp/Devices
what devices are available, and if there's only one and you're on it,
ct(1) will inform you that there are no devices available.

So you will have to start ct, being logged out. I use the following
Korn Shell alias:

alias callback='nohup sh -c "sleep 3; ct -s2400 123456">/dev/null & stty 0'

I suppose a Bourne Shell function could do the same trick.
-- 
--------------------+----------------------+-----------------------------------
Pim Zandbergen      | phone: +31 70 542302 | CTI Software BV
pim@ctisbv.UUCP     | fax  : +31 70 512837 | Laan Copes van Cattenburch 70
...!uunet!mcvax!hp4nl!ctisbv!pim           | 2585 GD The Hague, The Netherlands