Where does TERM get set for Telnet logins (NOT EXACTLY)

[Hascall John Paul]

In article <1990Dec19.181235.4193 at odin.corp.sgi.com>, olson at anchor.esd.sgi.com
(Dave Olson) writes:
> In <1990Dec18.074044.13043 at Think.COM> barmar at think.com (Barry Margolin)
writes:
> 
> | In article <1990Dec18.041334.7498 at ccu1.aukuni.ac.nz>
russell at ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
> | 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.

   They are not (as described above) exactly the same.  Under BSD if telnetd
cannot get a value for TERM from the other end, there is no TERM in login's
environment (even if there is a TERM in telnetd's environment).

--
John Hascall                        An ill-chosen word is the fool's messenger.
Project Vincent
Iowa State University Computation Center                       john at iastate.edu
Ames, IA  50010                                                  (515) 294-9551