Xref: utzoo unix-pc.general:1859 comp.unix.wizards:13397
Path: utzoo!utgpu!watmath!uunet!xanth!ames!mailrus!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: unix-pc.general,comp.unix.wizards
Subject: Re: Wanted: Intelligent getty program for SYS V
Message-ID: <7138@chinet.chi.il.us>
Date: 12 Dec 88 23:35:22 GMT
References: <822@kimbal.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 47

In article <822@kimbal.UUCP> rick@kimbal.UUCP (Rick Kimball) writes:
>I'm in search of the source code to an intelligent getty.
>Before I run off half-cocked and write my own, I thought
>I'd query the net to see if someone has already done it.

I started to work on something like this a few months ago but haven't
had time to do much (and it doesn't look good for the near future either).

>Have I missed anything?  I'm aware of "uutty" and it's
>almost exactly what I want.  But ...

I think you have the right ideas. My main problems with the normal
getty/uugetty are:

 1) Poor support for multiple speed modems.

 2) Slow login when the passwd file is large.
 
 3) No logfile.

One of the machines I work with handles a live database of agricultural
market information on a subscription basis.  It is accessed by a large
number of fairly non-technical users who want to log in quickly, make
their requests and log off.  Making getty also handle the login process
should speed things up, especially if it could use a hash table to
index the names (followed by a linear scan if the hash file happens to
be out of date).  The usual getty-type speed change (send a break, wait
a while, ad infinitum) is pretty annoying also, considering that the
modem tells you what speed it is going to use.  The logfile information
that I would like to see (only if the login fails) is every character
that was sent to the getty/login program and the date and time of the
call.  We have run across things like terminals (or emulators) that
send CR/LF/NULL when you hit return or XOFF/XON after each line.  The
current solution is to hook up a monitor terminal, which is difficult
because the inbound lines are on a roll-over and the subscribers often
don't have a second line to talk during the call.  A decent logfile would
make problem-solving much easier.
 
>    o   Provide dial in/out on same line.
>        Probably what I need is a wrapper proram that
>        will work with uucp, cu, etc...  It could
>        communicate with the getty program and let it know
>        when to stop and start.

The HDB uucp style locking and uugetty work pretty well. 

Les Mikesell