[lug] More on tset, ttytype, etc.

[John E. Koontz]

Peter Hutnick (off-list) has answered part of my questions by referring me 
to:

http://www.tldp.org/HOWTO/Text-Terminal-HOWTO.html

In which I find

===

14.7 Rarely Needed /etc/ttytype File
The configuration file /etc/ttytype is used to map /dev/ttySn's to terminal 
names per terminfo. tset uses it, but if the TERM environment variable is 
already set correctly, then this file is not needed. Since the Linux getty 
sets TERM for each tty, you don't need this file. In other Unix-like 
systems such as FreeBSD, the file /etc/ttys maps ttys to much more, such as 
the appropriate getty command, and the category of connection (such as 
"dialup"). An example line of Linux ttytype: vt220 ttyS1

===

Actually, some experimentation with Red Hat leads me to believe that if you 
are using X/Gnome (or gdm specifically?) in Red Hat 7 and 8, term does not 
get set at "login" at all.  It does get set when gnome terminal, xterm, 
etc., are started up.  In 7.2 it appears that term suddenly got set to dumb 
if you actually echoed the value.  ("Oops, that was supposed to be set!  If 
we set it now he'll never know the difference.")  If not, it remained 
quietly undefined until rather later.   These details of the seedy 
underside of term-setting in Linux seem not to have roused much interest on 
the Web, though I found some references to the correction of an 
unspecified  bugs.

Peter asked what the actual problem was.  OK -  it was a piece of code 
which I had mentioned in a much earlier post, from a generic cross-platform 
user configuration script, in which tset was being run to set term.  It was 
run in a while loop along the lines of "while term is dumb or some other 
fairly generic or undefined value, pester the user with tset to try set a 
more reasonable value of term."  This worked great with various commercial 
Unixes.  It was intended to handle actual hardware terminals and has 
continued to work with the versions of X used in these commercial Unixes, 
even though the actual dialog was no longer reaching the user and not 
actually needed.  In Red Hat Linux 7 and 8 it developed various problems, 
mainly due to term no longer being set previously and/or tset no longer 
deciding to use the default term offered in its ?-parameter if nobody 
actually answered its questions.

The solution is either to delete the while/tset loop entirely, or to 
execute it only if we're not using X (assume true if there's no DISPLAY env 
var).   It appears that in most cases in the contemporary Unix/Linux 
universe, tset is irrelevant.  Between better getty's, officious efforts on 
the part of ssh, rlogin, telnet, etc., and helpful X terminal clients, most 
modern Unixes set term for you quite satisfactorily, albeit the 
documentation may somewhat misrepresent the details of when and where.

Thanks, Peter!


John E. Koontz
NIST 896.04 PCSG
303-497-5180

N39° 59' 42.1" W 105° 15' 49.7"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20030328/d4c3c336/attachment.html>