Where does TERM get set for Telnet logins.

6 views
Skip to first unread message

Russell J Fulton;ccc032u

unread,
Dec 16, 1990, 10:43:30 PM12/16/90
to
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!)

In the mean time I need a way of telling telnetd what the default terminal
type to use.

Can anybody Help!!

Cheers, Russell.
--
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_f...@aukuni.ac.nz>

Vernon Schryver

unread,
Dec 17, 1990, 1:06:25 PM12/17/90
to
In article <1990Dec17.0...@ccu1.aukuni.ac.nz>, rus...@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
>...

> In the mean time I need a way of telling telnetd what the default terminal
> type to use.


"tset" might be useful, as in "eval `tset -s -Q`" somewhere in a .login file.
The shipped /.login contains an example. Notice that /etc/ttytypes can
contain "ttyq*" just as easily as "ttyd*". Tset(1) descripes solutions
to what sounds like the problem at hand.

Vernon Schryver, v...@sgi.com

Russell J Fulton;ccc032u

unread,
Dec 17, 1990, 11:13:34 PM12/17/90
to
rus...@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!

Barry Margolin

unread,
Dec 18, 1990, 2:40:44 AM12/18/90
to
In article <1990Dec18....@ccu1.aukuni.ac.nz> rus...@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.
--
Barry Margolin, Thinking Machines Corp.

bar...@think.com
{uunet,harvard}!think!barmar

Dan Bernstein

unread,
Dec 18, 1990, 4:35:53 AM12/18/90
to
In article <1990Dec18....@ccu1.aukuni.ac.nz> rus...@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
> 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.

No. The moral is that you should properly set up the environment of
daemons you start.

---Dan

Blair P. Houghton

unread,
Dec 18, 1990, 11:27:39 AM12/18/90
to
In article <1990Dec18....@ccu1.aukuni.ac.nz> rus...@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
>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.

You could unset/unsetenv TERM before starting that daemon, though yes,
there could be other lurking environment hooks for this and other daemons.

--Blair
"setenv VACATION Christmas"

Dave Olson

unread,
Dec 19, 1990, 1:12:35 PM12/19/90
to
In <1990Dec18.0...@Think.COM> bar...@think.com (Barry Margolin) writes:

| In article <1990Dec18....@ccu1.aukuni.ac.nz> rus...@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.

Russell J Fulton;ccc032u

unread,
Dec 19, 1990, 5:52:09 PM12/19/90
to
brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:

>---Dan

OK, I add the proviso: "Unless you know exactly what you are doing."

In a lot of cases now Unix systems are being administered by people who
do not have an encyclopedic knowledge of Unix. We have only had our system
for a year and are still finding out the finer points of its management.

Hascall John Paul

unread,
Jan 1, 1991, 11:43:35 AM1/1/91
to
In article <1990Dec19....@odin.corp.sgi.com>, ol...@anchor.esd.sgi.com

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 jo...@iastate.edu
Ames, IA 50010 (515) 294-9551

Vernon Schryver

unread,
Jan 2, 1991, 12:27:37 AM1/2/91
to
In article <1991Jan...@IASTATE.EDU>, jo...@IASTATE.EDU (Hascall John Paul) writes:
> ... They are not (as described above) exactly the same. Under BSD ...

To clear up any confusion among readers of the preceding thread, IRIX 3.3
telnet and telnetd are very 4.3BSD-Tahoe-ish. The modest source
differences are related to implementation details of things like PTY's and
SV signals. The IRIS 4D has always had 4.3BSD networking, with a slavish
but enthusiastic attitude toward BSD purity and 4.3 "diffability." I'm one
of the slaves.


Vernon Schryver, v...@sgi.com

Andrew Cherenson

unread,
Jan 3, 1991, 10:49:07 PM1/3/91
to

To be precise, the IRIX 3.3 telnetd is based on the
4.3BSD "networking release" version and the telnet command
is Dave Borman's March 1990 version.

deraadt

unread,
Jan 4, 1991, 2:45:42 AM1/4/91
to
In article <79...@sgi.sgi.com> a...@kaibab.wpd.sgi.com writes:
> In article <79...@sgi.sgi.com> v...@rhyolite.wpd.sgi.com writes:

> >In article <1991Jan...@IASTATE.EDU>, jo...@IASTATE.EDU writes:
> >> ... They are not (as described above) exactly the same. Under BSD ...
> >
> >To clear up any confusion among readers of the preceding thread, IRIX 3.3
> >telnet and telnetd are very 4.3BSD-Tahoe-ish. The modest source
> >differences are related to implementation details of things like PTY's and
> >SV signals. The IRIS 4D has always had 4.3BSD networking, with a slavish
> >but enthusiastic attitude toward BSD purity and 4.3 "diffability." I'm one
> >of the slaves.
> To be precise, the IRIX 3.3 telnetd is based on the
> 4.3BSD "networking release" version and the telnet command
> is Dave Borman's March 1990 version.
I thought that the original discussion was that login does not support the
-h flag, and that a telnetd started with a $TERM set would result in login
and telnetd providing telnetd's $TERM in the case when the correct $TERM
could not be determined.

I have no doubts that telnetd is 4.3 based. I would not want to write telnetd
from scratch and get all the nitty gritty details right (aside: I prefer the
simplicity and power of a real rlogin).

But SGI's login certainly does not appear to be derived from a BSD login
source of any kind. Boy, did I ever find that out when I tried to write
my own login for the iris's.

By the way, if anyone has a source to a login which works well on the iris,
I would *love* to get a copy. We need to insert a permissions library call
in the middle of login to determine if the person trying to login is
allowed on, based on his login name, tty, and groups.. managed through a
YP map called permissions.. Anyways, I'll be posting that library soon.
<tdr.

SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt
Is it a typo? Should the '_' be an 's'?? :-) | der...@cpsc.ucalgary.ca
--

SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt
Is it a typo? Should the '_' be an 's'?? :-) | der...@cpsc.ucalgary.ca

deraadt

unread,
Jan 4, 1991, 11:03:06 AM1/4/91
to
In article <DERAADT.91...@fsa.cpsc.ucalgary.ca> I write:
> I thought that the original discussion was that login does not support the
> -h flag, and that a telnetd started with a $TERM set would result in login
> and telnetd providing telnetd's $TERM in the case when the correct $TERM
> could not be determined.

Whoops. Mess up. I mean -p. Ie., when telnetd starts login, it is not
to provide the -p flag, and the result is that login is supposed to
discard the previous environment and build an environment completely
anew.

Getty, on the other hand, does supply -p, because getty builds part of
the environment, and login is supposed to just suppliment it.

Oh well. I think I'm getting religous about a BSDism in a system V group.
I should run for cover.
<tdr.

KP KP

unread,
Aug 1, 2022, 11:53:59 AMAug 1
to
Too bad your gaund paatgaye
Reply all
Reply to author
Forward
0 new messages