Xref: utzoo comp.sys.sgi:7403 comp.unix.internals:1553 Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!waikato!aukuni.ac.nz!russell From: russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) Newsgroups: comp.sys.sgi,comp.unix.internals Subject: Re: Where does TERM get set for Telnet logins.(Solution!) Message-ID: <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> Date: 18 Dec 90 04:13:34 GMT References: <1990Dec17.034330.27909@ccu1.aukuni.ac.nz> Distribution: comp Organization: University of Auckland, New Zealand. Lines: 44 russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >We are running an SGI 4D/240s with Irix 3.3.1. >Recently the default terminal type for telnet logins changed from vt220 to >wyse-50 and this has screwed up accounts who invoke tcsh as their login >shell. (tcsh uses the terminal type to recognise cursor keys and other >terminal features.) It would appear that tcsh uses the value of TERM that >was set when it was invoked and ignores changes to TERM thereafter ( as in the >.login file) >After a bit of hunting through man entries I find that login sets the TERM >variable from its environment. login is invoked by telnetd which will set the >TERM variable from information supplied by the client. The terminal emulator >we use (Based on ncsa telnet) does not set the terminal type. (This is to >be fixed soon!) With the help of several people, particularly Dave Olson of SGI I have figured out what happened. 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. This could only happen if it was inherited from the parent process (inetd). Thus inetd must have TERM set! Somebody must have started inetd from a terminal. A quick check verified that this was the case. We had had some problems with logins and the operators had stopped and restarted inetd from the system console (which was a wyse-50) and all network logins thereafter came in as wyse-50s. The moral of the story would appear to be Don't restart inetd from a terminal unless it is absolutely unavoidable. This probably applies to other daemons as well. If you do have to, then a boot of the system should be scheduled asap. Thanks again to all who responded. I had better ring the local SGI people to let them know that we have fixed the problem! Cheers, Russell. -- Russell Fulton, Computer Center, University of Auckland, New Zealand.