Xref: utzoo comp.sys.sgi:7477 comp.unix.internals:1608
Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!rex!ames!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi,comp.unix.internals
Subject: Re: Where does TERM get set for Telnet logins.(Solution!)
Message-ID: <1990Dec19.181235.4193@odin.corp.sgi.com>
Date: 19 Dec 90 18:12:35 GMT
References: <1990Dec17.034330.27909@ccu1.aukuni.ac.nz> <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> <1990Dec18.074044.13043@Think.COM>
Sender: news@odin.corp.sgi.com (Net News)
Distribution: comp
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 24

In <1990Dec18.074044.13043@Think.COM> barmar@think.com (Barry Margolin) writes:

| In article <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
| >Dave was able to supply the crucial information that telnetd does not set
| >TERM if negotiations with the client fail to produce a terminal type.
| >From this I concluded that TERM must be already set for the telnetd process.
| 
| The 4.3bsd telnetd doesn't have this problem.  If it is unable to negotiate
| the terminal type, it doesn't supply the "-p" (preserve environment) option
| to /bin/login.  And when it does negotiate the terminal type, it sets the
| environment that is inherited by /bin/login to only contain the TERM
| variable.
| 
| I suggest you ask your vendor to adopt this strategy.

This is exactly how it works.  However, if TERM isn't passed in to login
by telnetd, AND TERM is already set in the environment, then login will
use the value already in the environment, which in this case was inherited
down the chain from the operator's shell -> inetd -> telnetd -> login.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.