Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Feb 1997 13:30:31 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        davidn@unique.usn.blaze.net.au (David Nugent)
Cc:        freebsd-current@freebsd.org
Subject:   Re: getty patches
Message-ID:  <199702022030.NAA08495@phaeton.artisoft.com>
In-Reply-To: <19970202171317.RP40411@usn.blaze.net.au> from "David Nugent" at Feb 2, 97 05:13:17 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> I have implemented the following in /usr/libexec/getty:
> 
> 1)	Ability to define a modem initialisation script.
> 	The port is opened in non-blocking mode, and a
> 	send/expect chat script is executed. If modem
> 	initialisation fails, getty recycles.
> 
> 	gettytab capabilities:
> 
> 		ic=expect send [expect send ...]
> 			init chat script
> 		ct#val
> 			chat timeout in seconds

Er, what happens if it always fails because the modem is off or has
been taken away entirely?  Does it spin forever, or will it eventually
give up?


> 3)	A recycle time value, to getty to be periodically
> 	recycled and initialised after a given number of
> 	seconds if there is no activity detected.
> 
> 	gettytab capabilities:
> 
> 		rt#val
> 			recycle time in seconds

What's this for?

> 6)	Fixed bugs in the %s, %m, %r and %v macros which don't
> 	currently work [uname() was never being called, thus
> 	the values for these were always blank. rlogin seems to
> 	suffer the same bug].

Good deal.

> 7)	Sending a sysv-like "issue" file prior the login prompt.
> 	This is much more useful than the 'im=' capability since
> 	it can be more easily modified by scripts etc.
> 
> 	gettytab capabilities:
> 
> 		if=<filename>
> 
> 	(I saw some chat about this a while back on the mailing
> 	list, but alas, no commit resulted).

I'm pro this one, but it's arguable.

> Does anyone have any objecting to me committing these changes?
> I believe they bring our getty more in line with modem technology
> that has been available for over a decade now. :-)

There are a number of people who have been working on login.conf
changes; at the very least, your /etc/issue capability probably
conflicts with this.

I also find it alarming to allow the open to succeed without a
call being present... how do I use the same modem port for
outbound traffic?  How do I build a pseduo-device split, so I
can have a device for outbound calls and one for inbound calls,
if you always open the thing for inbound processing?


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702022030.NAA08495>